From kmacmill at redhat.com Thu Nov 1 14:48:07 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 01 Nov 2007 10:48:07 -0400 Subject: [Freeipa-devel] [PATCH] update version numbers for release Message-ID: <1193928487.3004.39.camel@localhost.localdomain> -------------- next part -------------- A non-text attachment was scrubbed... Name: release.patch Type: text/x-patch Size: 9149 bytes Desc: not available URL: From rcritten at redhat.com Thu Nov 1 15:03:44 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 Nov 2007 11:03:44 -0400 Subject: [Freeipa-devel] [PATCH] update version numbers for release In-Reply-To: <1193928487.3004.39.camel@localhost.localdomain> References: <1193928487.3004.39.camel@localhost.localdomain> Message-ID: <4729EAD0.6060805@redhat.com> Looks good. My only question is why ipa-client is at 0.3 and everything else is at 0.4. 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 kmacmill at redhat.com Thu Nov 1 15:25:13 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 01 Nov 2007 11:25:13 -0400 Subject: [Freeipa-devel] [PATCH] update version numbers for release In-Reply-To: <4729EAD0.6060805@redhat.com> References: <1193928487.3004.39.camel@localhost.localdomain> <4729EAD0.6060805@redhat.com> Message-ID: <1193930713.3004.41.camel@localhost.localdomain> On Thu, 2007-11-01 at 11:03 -0400, Rob Crittenden wrote: > Looks good. My only question is why ipa-client is at 0.3 and everything > else is at 0.4. > Pushed with a tag. From kmacmill at redhat.com Thu Nov 1 15:27:51 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 01 Nov 2007 11:27:51 -0400 Subject: [Freeipa-devel] Milestone 4 Update 1 released Message-ID: <1193930871.3004.45.camel@localhost.localdomain> An update to Milestone 4 has been released. Milestone 5 is not far away, but the progress since Milestone 4 has already been huge and we wanted to get a new release out for testing. Still primarily aimed at developers. I also reorganized the download directory and the yum repos. There is now a repo for i386 and x86_64 on Fedora 7 and the organization is in place to support repos for Fedora 8 when it's released. Your existing yum repo will no longer work (sorry). Karl From rcritten at redhat.com Thu Nov 1 15:56:33 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 Nov 2007 11:56:33 -0400 Subject: [Freeipa-devel] [PATCH] TurboGears logging Message-ID: <4729F731.2010904@redhat.com> TurboGears log files and log rotation The error log is rotated weekly on Sunday. 4 backups are saved. The access log is not stored since it would be a duplicate of the Apache logs. It can be enabled if desired. Had to move the call to daemonize() in ipa-webgui so that the fork is done before TurboGears is initialized. Otherwise the log files end up getting closed. I added a try/except around the forks too. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-344-logs.patch Type: text/x-patch Size: 2954 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 Thu Nov 1 16:50:12 2007 From: jdennis at redhat.com (John Dennis) Date: Thu, 01 Nov 2007 12:50:12 -0400 Subject: [Freeipa-devel] Milestone 4 Update 1 released In-Reply-To: <1193930871.3004.45.camel@localhost.localdomain> References: <1193930871.3004.45.camel@localhost.localdomain> Message-ID: <472A03C4.6020308@redhat.com> Karl MacMillan wrote: > I also reorganized the download directory and the yum repos. ... > Your existing yum repo will no longer work (sorry). The no longer working part might be a bit confusing without pointing folks to where then can get a new freeipa.repo file which will work, it can be found here: http://freeipa.com/page/Downloads -- John Dennis From rcritten at redhat.com Thu Nov 1 17:21:32 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 Nov 2007 13:21:32 -0400 Subject: [Freeipa-devel] [PATCH] fix ipa-findgroup Message-ID: <472A0B1C.4000604@redhat.com> I was using the wrong access methods in ipa-findgroup. Not sure how this worked in previous testing... rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-345-findgroup.patch Type: text/x-patch Size: 753 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 Nov 1 17:59:13 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 01 Nov 2007 13:59:13 -0400 Subject: [Freeipa-devel] [patch] fix exit condition Message-ID: <472A13F1.4030403@redhat.com> os.exit() does not exist, replace with the correct sys.exit() fixes #70 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-349-sysexit.patch Type: text/x-patch Size: 1543 bytes Desc: not available URL: From smooge at gmail.com Thu Nov 1 18:03:58 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 1 Nov 2007 12:03:58 -0600 Subject: [Freeipa-devel] Milestone 4 Update 1 released In-Reply-To: <1193930871.3004.45.camel@localhost.localdomain> References: <1193930871.3004.45.camel@localhost.localdomain> Message-ID: <80d7e4090711011103j6e18c0d7n754b164d9d2455ae@mail.gmail.com> On 11/1/07, Karl MacMillan wrote: > An update to Milestone 4 has been released. Milestone 5 is not far away, > but the progress since Milestone 4 has already been huge and we wanted > to get a new release out for testing. > > Still primarily aimed at developers. > > I also reorganized the download directory and the yum repos. There is > now a repo for i386 and x86_64 on Fedora 7 and the organization is in > place to support repos for Fedora 8 when it's released. Your existing > yum repo will no longer work (sorry). > Between Milestone 5 and Release 1 will there be a beta schedule.. I would like to put up a 'preview' server set to 'show-off' evaluate to management sometime but the 'aimed at developers' etc kind of scares off the middle-managers. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From kmacmill at redhat.com Thu Nov 1 18:18:23 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 01 Nov 2007 14:18:23 -0400 Subject: [Freeipa-devel] Milestone 4 Update 1 released In-Reply-To: <80d7e4090711011103j6e18c0d7n754b164d9d2455ae@mail.gmail.com> References: <1193930871.3004.45.camel@localhost.localdomain> <80d7e4090711011103j6e18c0d7n754b164d9d2455ae@mail.gmail.com> Message-ID: <1193941103.3083.3.camel@localhost.localdomain> On Thu, 2007-11-01 at 12:03 -0600, Stephen John Smoogen wrote: > On 11/1/07, Karl MacMillan wrote: > > An update to Milestone 4 has been released. Milestone 5 is not far away, > > but the progress since Milestone 4 has already been huge and we wanted > > to get a new release out for testing. > > > > Still primarily aimed at developers. > > > > I also reorganized the download directory and the yum repos. There is > > now a repo for i386 and x86_64 on Fedora 7 and the organization is in > > place to support repos for Fedora 8 when it's released. Your existing > > yum repo will no longer work (sorry). > > > > Between Milestone 5 and Release 1 will there be a beta schedule.. I > would like to put up a 'preview' server set to 'show-off' evaluate to > management sometime but the 'aimed at developers' etc kind of scares > off the middle-managers. > Yes - glad to hear you are wanting to try things out. Milestone 5 (currently Nov. 9) will be feature complete and will begin our testing phase. We plan to test and document for about a month after Milestone 5 - with at least a few test releases - before we do a freeipa release 1. The only reason I don't recommend the current release for non-developers is that the uid/gid autogeneration is still not turned on. That prevents creating users that can actually be used. I expect Milestone 5 to be useful for testers. Hope that answers the question. Karl From smooge at gmail.com Thu Nov 1 18:50:51 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 1 Nov 2007 12:50:51 -0600 Subject: [Freeipa-devel] Milestone 4 Update 1 released In-Reply-To: <1193941103.3083.3.camel@localhost.localdomain> References: <1193930871.3004.45.camel@localhost.localdomain> <80d7e4090711011103j6e18c0d7n754b164d9d2455ae@mail.gmail.com> <1193941103.3083.3.camel@localhost.localdomain> Message-ID: <80d7e4090711011150i5cd08b90nf8bd860abdc5c39f@mail.gmail.com> On 11/1/07, Karl MacMillan wrote: > On Thu, 2007-11-01 at 12:03 -0600, Stephen John Smoogen wrote: > > On 11/1/07, Karl MacMillan wrote: > > > An update to Milestone 4 has been released. Milestone 5 is not far away, > > > but the progress since Milestone 4 has already been huge and we wanted > > > to get a new release out for testing. > > > > > > Still primarily aimed at developers. > > > > > > I also reorganized the download directory and the yum repos. There is > > > now a repo for i386 and x86_64 on Fedora 7 and the organization is in > > > place to support repos for Fedora 8 when it's released. Your existing > > > yum repo will no longer work (sorry). > > > > > > > Between Milestone 5 and Release 1 will there be a beta schedule.. I > > would like to put up a 'preview' server set to 'show-off' evaluate to > > management sometime but the 'aimed at developers' etc kind of scares > > off the middle-managers. > > > > Yes - glad to hear you are wanting to try things out. Milestone 5 > (currently Nov. 9) will be feature complete and will begin our testing > phase. We plan to test and document for about a month after Milestone 5 > - with at least a few test releases - before we do a freeipa release 1. > > The only reason I don't recommend the current release for non-developers > is that the uid/gid autogeneration is still not turned on. That prevents > creating users that can actually be used. I expect Milestone 5 to be > useful for testers. > > Hope that answers the question. > Yes it does thanks. The problem with showing things to management, if they like it they will say something like "So we can have this ready on Monday?" and then I have to hedge and the AD people say "Sure" with that red glow in their eyes :) -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From rcritten at redhat.com Thu Nov 1 19:28:38 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 Nov 2007 15:28:38 -0400 Subject: [Freeipa-devel] [patch] fix exit condition In-Reply-To: <472A13F1.4030403@redhat.com> References: <472A13F1.4030403@redhat.com> Message-ID: <472A28E6.1050801@redhat.com> Simo Sorce wrote: > os.exit() does not exist, replace with the correct sys.exit() > fixes #70 > Looks good. 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 kmacmill at redhat.com Thu Nov 1 19:35:09 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 01 Nov 2007 15:35:09 -0400 Subject: [Freeipa-devel] [PATCH] NTP configuration for client and server Message-ID: <919346fa283e74afc386.1193945709@cage.mentalrootkit.com> # HG changeset patch # User "Karl MacMillan " # Date 1193945702 14400 # Node ID 919346fa283e74afc386a46b7ec3e6f27af4af12 # Parent c0f72de1e5d83c8536a46c193989b78609506c29 NTP configuration for client and server. Configure ipa servers as an ntp server and clients to (by default) us the ipa server as an ntp server. Also corrected the messages about which ports should be opened. diff -r c0f72de1e5d8 -r 919346fa283e ipa-client/ipa-install/ipa-client-install --- a/ipa-client/ipa-install/ipa-client-install Thu Nov 01 11:23:34 2007 -0400 +++ b/ipa-client/ipa-install/ipa-client-install Thu Nov 01 15:35:02 2007 -0400 @@ -30,6 +30,7 @@ from optparse import OptionParser from optparse import OptionParser import ipaclient.ipadiscovery import ipaclient.ipachangeconf +import ipaclient.ntpconf from ipa.ipautil import run def parse_options(): @@ -43,6 +44,8 @@ def parse_options(): default=False, help="print debugging information") parser.add_option("-U", "--unattended", dest="unattended", help="unattended installation never prompts the user") + parser.add_option("-N", "--no-ntp", action="store_false", + help="do not configure ntp", default=True, dest="conf_ntp") options, args = parser.parse_args() @@ -67,14 +70,6 @@ def logging_setup(options): console.setFormatter(formatter) logging.getLogger('').addHandler(console) -def check_ntp(): - ret_code = 1 - p = subprocess.Popen(["/sbin/service", "ntpd", "status"], stdout=subprocess.PIPE, - stderr=subprocess.PIPE) - stdout, stderr = p.communicate() - - return p.returncode - def main(): options = parse_options() logging_setup(options) @@ -208,10 +203,8 @@ def main(): #Modify pam to add pam_krb5 run(["/usr/sbin/authconfig", "--enablekrb5", "--update"]) - # print warning about ntp - if check_ntp() != 0: - print "WARNING: Kerberos requires time synchronization between clients" - print "and servers for correct operation. You should consider enabling ntpd." + if options.conf_ntp: + ipaclient.ntpconf.config_ntp(ds.getServerName()) return 0 diff -r c0f72de1e5d8 -r 919346fa283e ipa-client/ipaclient/Makefile.am --- a/ipa-client/ipaclient/Makefile.am Thu Nov 01 11:23:34 2007 -0400 +++ b/ipa-client/ipaclient/Makefile.am Thu Nov 01 15:35:02 2007 -0400 @@ -6,6 +6,7 @@ app_PYTHON = \ dnsclient.py \ ipachangeconf.py \ ipadiscovery.py \ + ntpconf.py \ $(NULL) EXTRA_DIST = \ diff -r c0f72de1e5d8 -r 919346fa283e ipa-client/ipaclient/ntpconf.py --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/ipa-client/ipaclient/ntpconf.py Thu Nov 01 15:35:02 2007 -0400 @@ -0,0 +1,89 @@ +# Authors: Karl MacMillan +# +# Copyright (C) 2007 Red Hat +# see file 'COPYING' for use and warranty information +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; version 2 or later +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA +# + +from ipa.ipautil import * +import shutil + +ntp_conf = """# Permit time synchronization with our time source, but do not +# permit the source to query or modify the service on this system. +restrict default kod nomodify notrap nopeer noquery +restrict -6 default kod nomodify notrap nopeer noquery + +# Permit all access over the loopback interface. This could +# be tightened as well, but to do so would effect some of +# the administrative functions. +restrict 127.0.0.1 +restrict -6 ::1 + +# Hosts on local network are less restricted. +#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap + +# Use public servers from the pool.ntp.org project. +# Please consider joining the pool (http://www.pool.ntp.org/join.html). +server $SERVER + +#broadcast 192.168.1.255 key 42 # broadcast server +#broadcastclient # broadcast client +#broadcast 224.0.1.1 key 42 # multicast server +#multicastclient 224.0.1.1 # multicast client +#manycastserver 239.255.254.254 # manycast server +#manycastclient 239.255.254.254 key 42 # manycast client + +# Undisciplined Local Clock. This is a fake driver intended for backup +# and when no outside source of synchronized time is available. +server 127.127.1.0 # local clock +#fudge 127.127.1.0 stratum 10 + +# Drift file. Put this in a directory which the daemon can write to. +# No symbolic links allowed, either, since the daemon updates the file +# by creating a temporary in the same directory and then rename()'ing +# it to the file. +driftfile /var/lib/ntp/drift + +# Key file containing the keys and key identifiers used when operating +# with symmetric key cryptography. +keys /etc/ntp/keys + +# Specify the key identifiers which are trusted. +#trustedkey 4 8 42 + +# Specify the key identifier to use with the ntpdc utility. +#requestkey 8 + +# Specify the key identifier to use with the ntpq utility. +#controlkey 8 +""" + +def config_ntp(server_fqdn): + sub_dict = { } + sub_dict["SERVER"] = server_fqdn + + nc = template_str(ntp_conf, sub_dict) + + shutil.copy("/etc/ntp.conf", "/etc/ntp.conf.ipasave") + + fd = open("/etc/ntp.conf", "w") + fd.write(nc) + fd.close() + + # Set the ntpd to start on boot + run(["/sbin/chkconfig", "ntpd", "on"]) + + # Restart ntpd + run(["/sbin/service", "ntpd", "restart"]) diff -r c0f72de1e5d8 -r 919346fa283e ipa-server/ipa-install/ipa-server-install --- a/ipa-server/ipa-install/ipa-server-install Thu Nov 01 11:23:34 2007 -0400 +++ b/ipa-server/ipa-install/ipa-server-install Thu Nov 01 15:35:02 2007 -0400 @@ -41,10 +41,13 @@ import glob import glob import traceback from optparse import OptionParser + import ipaserver.dsinstance import ipaserver.krbinstance import ipaserver.bindinstance import ipaserver.httpinstance +import ipaserver.ntpinstance + from ipa.ipautil import run def parse_options(): @@ -542,6 +545,10 @@ def main(): ds.restart() krb.restart() + # Configure ntpd + ntp = ipaserver.ntpinstance.NTPInstance() + ntp.create_instance() + try: selinux=0 try: @@ -588,6 +595,12 @@ def main(): # Start Kpasswd run(["/sbin/service", "ipa-kpasswd", "start"]) + + # Set the ntpd to start on boot + run(["/sbin/chkconfig", "ntpd", "on"]) + + # Restart ntpd + run(["/sbin/service", "ntpd", "restart"]) except subprocess.CalledProcessError, e: print "Installation failed:", e return 1 @@ -610,9 +623,10 @@ def main(): print "\t\tTCP Ports:" print "\t\t * 80, 443, 8080: HTTP/HTTPS" print "\t\t * 389, 636: LDAP/LDAPS" - print "\t\t * 464: kpasswd" + print "\t\t * 88, 464: kerberos" print "\t\tUDP Ports:" - print "\t\t * 88, 750: kerberos" + print "\t\t * 88, 464: kerberos" + print "\t\t * 123: ntp" print "" print "\t2. You can now obtain a kerberos ticket using the command: 'kinit admin'." print "\t This ticket will allow you to use the IPA tools (e.g., ipa-adduser)" diff -r c0f72de1e5d8 -r 919346fa283e ipa-server/ipa-install/share/Makefile.am --- a/ipa-server/ipa-install/share/Makefile.am Thu Nov 01 11:23:34 2007 -0400 +++ b/ipa-server/ipa-install/share/Makefile.am Thu Nov 01 15:35:02 2007 -0400 @@ -16,6 +16,7 @@ app_DATA = \ krb5.ini.template \ krb.con.template \ krbrealm.con.template \ + ntp.conf.server.template \ $(NULL) EXTRA_DIST = \ diff -r c0f72de1e5d8 -r 919346fa283e ipa-server/ipa-install/share/ntp.conf.server.template --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/ipa-server/ipa-install/share/ntp.conf.server.template Thu Nov 01 15:35:02 2007 -0400 @@ -0,0 +1,50 @@ +# Permit time synchronization with our time source, but do not +# permit the source to query or modify the service on this system. +restrict default kod nomodify notrap +restrict -6 default kod nomodify notrap + +# Permit all access over the loopback interface. This could +# be tightened as well, but to do so would effect some of +# the administrative functions. +restrict 127.0.0.1 +restrict -6 ::1 + +# Hosts on local network are less restricted. +#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap + +# Use public servers from the pool.ntp.org project. +# Please consider joining the pool (http://www.pool.ntp.org/join.html). +server $SERVERA +server $SERVERB +server $SERVERC + +#broadcast 192.168.1.255 key 42 # broadcast server +#broadcastclient # broadcast client +#broadcast 224.0.1.1 key 42 # multicast server +#multicastclient 224.0.1.1 # multicast client +#manycastserver 239.255.254.254 # manycast server +#manycastclient 239.255.254.254 key 42 # manycast client + +# Undisciplined Local Clock. This is a fake driver intended for backup +# and when no outside source of synchronized time is available. +server 127.127.1.0 # local clock +#fudge 127.127.1.0 stratum 10 + +# Drift file. Put this in a directory which the daemon can write to. +# No symbolic links allowed, either, since the daemon updates the file +# by creating a temporary in the same directory and then rename()'ing +# it to the file. +driftfile /var/lib/ntp/drift + +# Key file containing the keys and key identifiers used when operating +# with symmetric key cryptography. +keys /etc/ntp/keys + +# Specify the key identifiers which are trusted. +#trustedkey 4 8 42 + +# Specify the key identifier to use with the ntpdc utility. +#requestkey 8 + +# Specify the key identifier to use with the ntpq utility. +#controlkey 8 diff -r c0f72de1e5d8 -r 919346fa283e ipa-server/ipaserver/Makefile.am --- a/ipa-server/ipaserver/Makefile.am Thu Nov 01 11:23:34 2007 -0400 +++ b/ipa-server/ipaserver/Makefile.am Thu Nov 01 15:35:02 2007 -0400 @@ -8,6 +8,7 @@ app_PYTHON = \ ipaldap.py \ krbinstance.py \ httpinstance.py \ + ntpinstance.py \ $(NULL) EXTRA_DIST = \ diff -r c0f72de1e5d8 -r 919346fa283e ipa-server/ipaserver/dsinstance.py --- a/ipa-server/ipaserver/dsinstance.py Thu Nov 01 11:23:34 2007 -0400 +++ b/ipa-server/ipaserver/dsinstance.py Thu Nov 01 15:35:02 2007 -0400 @@ -26,8 +26,6 @@ import pwd import pwd from ipa.ipautil import * - -SHARE_DIR = "/usr/share/ipa/" SERVER_ROOT_64 = "/usr/lib64/dirsrv" SERVER_ROOT_32 = "/usr/lib/dirsrv" diff -r c0f72de1e5d8 -r 919346fa283e ipa-server/ipaserver/ntpinstance.py --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/ipa-server/ipaserver/ntpinstance.py Thu Nov 01 15:35:02 2007 -0400 @@ -0,0 +1,50 @@ +# Authors: Karl MacMillan +# +# Copyright (C) 2007 Red Hat +# see file 'COPYING' for use and warranty information +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; version 2 or later +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA +# + +from ipa.ipautil import * +import shutil + +class NTPInstance: + def create_instance(self): + # The template sets the config to point towards ntp.pool.org, but + # they request that software not point towards the default pool. + # We use the OS variable to point it towards either the rhel + # or fedora pools. Other distros should be added in the future + # or we can get our own pool. + os = "" + if file_exists("/etc/fedora-release"): + os = "fedora." + elif file_exists("/etc/redhat-release"): + os = "rhel." + + sub_dict = { } + sub_dict["SERVERA"] = "0.%spool.ntp.org" % os + sub_dict["SERVERB"] = "1.%spool.ntp.org" % os + sub_dict["SERVERC"] = "2.%spool.ntp.org" % os + + ntp_conf = template_file(SHARE_DIR + "ntp.conf.server.template", sub_dict) + + shutil.copy("/etc/ntp.conf", "/etc/ntp.conf.ipasave") + + fd = open("/etc/ntp.conf", "w") + fd.write(ntp_conf) + fd.close() + + # we might consider setting the date manually using ntpd -qg in case + # the current time is very far off. From ssorce at redhat.com Thu Nov 1 20:02:05 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 01 Nov 2007 16:02:05 -0400 Subject: [Freeipa-devel] [PATCH] NTP configuration for client and server In-Reply-To: <919346fa283e74afc386.1193945709@cage.mentalrootkit.com> References: <919346fa283e74afc386.1193945709@cage.mentalrootkit.com> Message-ID: <1193947325.12404.26.camel@localhost.localdomain> On Thu, 2007-11-01 at 15:35 -0400, Karl MacMillan wrote: > NTP configuration for client and server. Can you put the ntp.conf template in a file, it makes it much easier to customize the configuration if you have to edit a file instead of a python script. > Configure ipa servers as an ntp server and clients > to (by default) us the ipa server as an ntp server. I think we should do an ntpdate before starting ntp to make sure the clock is correctly synchronized before starting the daemon. if the skew is too big ntpd will not be able to compensate otherwise. Simo. From rcritten at redhat.com Thu Nov 1 20:16:45 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 Nov 2007 16:16:45 -0400 Subject: [Freeipa-devel] [PATCH] new look and feel Message-ID: <472A342D.1020105@redhat.com> Patch to completely revamp the GUI look and feel. Contributed by M?ir?n Duffy. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-339-gui.patch Type: text/x-patch Size: 100848 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 kmacmill at redhat.com Fri Nov 2 13:48:22 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Fri, 02 Nov 2007 09:48:22 -0400 Subject: [Freeipa-devel] [PATCH] NTP configuration for client and server In-Reply-To: <1193947325.12404.26.camel@localhost.localdomain> References: <919346fa283e74afc386.1193945709@cage.mentalrootkit.com> <1193947325.12404.26.camel@localhost.localdomain> Message-ID: <1194011302.4611.5.camel@localhost.localdomain> On Thu, 2007-11-01 at 16:02 -0400, Simo Sorce wrote: > On Thu, 2007-11-01 at 15:35 -0400, Karl MacMillan wrote: > > NTP configuration for client and server. > > Can you put the ntp.conf template in a file, it makes it much easier to > customize the configuration if you have to edit a file instead of a > python script. > I could, but currently we don't have a good place to put that for the client. So I agree that the template file is nicer, but unless you fell this is very important I'd rather not spend the time doing it. > > Configure ipa servers as an ntp server and clients > > to (by default) us the ipa server as an ntp server. > > I think we should do an ntpdate before starting ntp to make sure the > clock is correctly synchronized before starting the daemon. > if the skew is too big ntpd will not be able to compensate otherwise. > Ok - I'll send another patch that does this. Karl From jonstanley at gmail.com Fri Nov 2 14:38:08 2007 From: jonstanley at gmail.com (Jon Stanley) Date: Fri, 2 Nov 2007 10:38:08 -0400 Subject: [Freeipa-devel] Some WebUI observations Message-ID: I just installed milestone 4, updated to update 1 last night, and found a few things about the UI that probably need some attention (I know that Marian has been working on some UI stuff that's not in yet): 1) If you attempt to access the site without having a valid Kerberos ticket, a page comes up talking about an idm wiki, calling the helpdesk, etc (forget the exact wording, I'm not at home where I've got a browser that can access my FreeIPA server). This is obviously a stale message, but where does it come from? It should be configurable to allow the admin to put something to the effect of 'You've tried to access Company XYZ's FreeIPA server, however, you do not have a Kerberos ticket. Obtain one via kinit, or if you are having difficulties, contact the helpdesk at xxx-xxx-xxxx" 2) Adding users has no option to override auto UID/GID generation. This would be quite useful. 3) There appears to be no interface for organizing users into OU's - am I missing something or is this coming in a future release? 4) I created a user, got rid of my tickets using kdestroy, used kinit as that new user, and went to the website. All of the links were still there that were when I was admin. I clicked add user and it brought up the form. Filled out the form and hit submit, it simply said that 'a database error occured', not that I didn't have permissions to perform the action. Ideally, I wouldn't be able to see the link to add a user, and if I were, I should be told that I don't have permission instead of being presented with the form. I could not find an error anywhere that explicitly stated that I didn't have permissions, either. The closest thing that I found was a cryptic entry in the FDS access log: [02/Nov/2007:08:19:41 -0400] conn=18 op=3 ADD dn="uid=jdoe,cn=users,cn=accounts,dc=rmrf,dc=net" [02/Nov/2007:08:19:41 -0400] conn=18 op=3 RESULT err=50 tag=105 nentries=0 etime=0 5) I don't think that the settings page is implemented yet. When it is, there should be an option for the default e-mail format and cn schema. That's all that I can think of for now, I'm sure that there's more that I just can't think about this early in the morning -Jon From kmacmill at redhat.com Fri Nov 2 14:49:32 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Fri, 02 Nov 2007 10:49:32 -0400 Subject: [Freeipa-devel] [PATCH] completely remove an attribute In-Reply-To: <4728EFCA.2010103@redhat.com> References: <4728EFCA.2010103@redhat.com> Message-ID: <1194014972.4611.46.camel@localhost.localdomain> On Wed, 2007-10-31 at 17:12 -0400, Rob Crittenden wrote: > This should make ipa-usermod nicer. Add a function to completely remove > an attribute (if it exists). > > Usage is something like: user.delValue('telephonenumber') > Pushed. From kmacmill at redhat.com Fri Nov 2 14:51:49 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Fri, 02 Nov 2007 10:51:49 -0400 Subject: [Freeipa-devel] [PATCH] TurboGears logging In-Reply-To: <4729F731.2010904@redhat.com> References: <4729F731.2010904@redhat.com> Message-ID: <1194015109.4611.48.camel@localhost.localdomain> On Thu, 2007-11-01 at 11:56 -0400, Rob Crittenden wrote: > TurboGears log files and log rotation > > The error log is rotated weekly on Sunday. 4 backups are saved. > > The access log is not stored since it would be a duplicate of the > Apache logs. It can be enabled if desired. > > Had to move the call to daemonize() in ipa-webgui so that the > fork is done before TurboGears is initialized. Otherwise the log > files end up getting closed. > > I added a try/except around the forks too. > Pushed. From kmacmill at redhat.com Fri Nov 2 14:52:29 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Fri, 02 Nov 2007 10:52:29 -0400 Subject: [Freeipa-devel] [PATCH] fix ipa-findgroup In-Reply-To: <472A0B1C.4000604@redhat.com> References: <472A0B1C.4000604@redhat.com> Message-ID: <1194015150.4611.50.camel@localhost.localdomain> On Thu, 2007-11-01 at 13:21 -0400, Rob Crittenden wrote: > I was using the wrong access methods in ipa-findgroup. Not sure how this > worked in previous testing... > Pushed. From kmacmill at redhat.com Fri Nov 2 14:55:09 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Fri, 02 Nov 2007 10:55:09 -0400 Subject: [Freeipa-devel] [PATCH] new look and feel In-Reply-To: <472A342D.1020105@redhat.com> References: <472A342D.1020105@redhat.com> Message-ID: <1194015309.4611.53.camel@localhost.localdomain> On Thu, 2007-11-01 at 16:16 -0400, Rob Crittenden wrote: > Patch to completely revamp the GUI look and feel. Contributed by M?ir?n > Duffy. > Overall looks much better - I'll try to get some screenshots up. We can polish as necessary once this is in the tree. Pushed. Karl From kmacmill at redhat.com Fri Nov 2 15:11:21 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Fri, 02 Nov 2007 11:11:21 -0400 Subject: [Freeipa-devel] Some WebUI observations In-Reply-To: References: Message-ID: <1194016281.4611.69.camel@localhost.localdomain> On Fri, 2007-11-02 at 10:38 -0400, Jon Stanley wrote: > I just installed milestone 4, updated to update 1 last night, and > found a few things about the UI that probably need some attention (I > know that Marian has been working on some UI stuff that's not in yet): > > 1) If you attempt to access the site without having a valid Kerberos > ticket, a page comes up talking about an idm wiki, calling the > helpdesk, etc (forget the exact wording, I'm not at home where I've > got a browser that can access my FreeIPA server). This is obviously a > stale message, but where does it come from? It should be configurable > to allow the admin to put something to the effect of 'You've tried to > access Company XYZ's FreeIPA server, however, you do not have a > Kerberos ticket. Obtain one via kinit, or if you are having > difficulties, contact the helpdesk at xxx-xxx-xxxx" > Agreed - fwiw the current page was adopted from an internal project. It didn't get fully cleaned up. Added ticket #72 > 2) Adding users has no option to override auto UID/GID generation. > This would be quite useful. > You can do this with the commandline tools - I'd like to see this in the gui as well. Added ticket #73 - hopefully we can get this in. > 3) There appears to be no interface for organizing users into OU's - > am I missing something or is this coming in a future release? > Future release I think. Right now you will have to use groups. How would you like this feature to look? Let the fact that there is an ldap tree leak out? Or have something more abstract, like the ability to create departments, groups, etc. and organize people into an org chart? Pete / Simo - in the past I think you have argued against reflecting organizational structure in the ldap tree. Can you elaborate? Added ticket #74. > 4) I created a user, got rid of my tickets using kdestroy, used kinit > as that new user, and went to the website. All of the links were > still there that were when I was admin. I clicked add user and it > brought up the form. Filled out the form and hit submit, it simply > said that 'a database error occured', not that I didn't have > permissions to perform the action. Ideally, I wouldn't be able to see > the link to add a user, and if I were, I should be told that I don't > have permission instead of being presented with the form. I could not > find an error anywhere that explicitly stated that I didn't have > permissions, either. The closest thing that I found was a cryptic > entry in the FDS access log: > > [02/Nov/2007:08:19:41 -0400] conn=18 op=3 ADD > dn="uid=jdoe,cn=users,cn=accounts,dc=rmrf,dc=net" > [02/Nov/2007:08:19:41 -0400] conn=18 op=3 RESULT err=50 tag=105 > nentries=0 etime=0 > What we wanted for this was to have the gui reflect what access the current user has, down to the field level. Since we have the ability to delegate access in a fine-grained way this is what is really needed. That allows you to, say, allow an office manager to change telephone numbers and addresses for everyone in the group that represents their office but not have other access. Unfortunately, we may not have time to finish that feature. The alternative is to provide better error reporting. ticket #21 covers this. > 5) I don't think that the settings page is implemented yet. When it > is, there should be an option for the default e-mail format and cn > schema. > We may not have gui in v1 for some of the settings. Instead we'll provide instructions on how to change the settings manually (which will be stored in ldap). > That's all that I can think of for now, I'm sure that there's more > that I just can't think about this early in the morning > Thanks for the feedback! Karl From ssorce at redhat.com Fri Nov 2 15:13:03 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 02 Nov 2007 11:13:03 -0400 Subject: [Freeipa-devel] [PATCH] NTP configuration for client and server In-Reply-To: <1194011302.4611.5.camel@localhost.localdomain> References: <919346fa283e74afc386.1193945709@cage.mentalrootkit.com> <1193947325.12404.26.camel@localhost.localdomain> <1194011302.4611.5.camel@localhost.localdomain> Message-ID: <1194016383.12404.32.camel@localhost.localdomain> On Fri, 2007-11-02 at 09:48 -0400, Karl MacMillan wrote: > On Thu, 2007-11-01 at 16:02 -0400, Simo Sorce wrote: > > On Thu, 2007-11-01 at 15:35 -0400, Karl MacMillan wrote: > > > NTP configuration for client and server. > > > > Can you put the ntp.conf template in a file, it makes it much easier to > > customize the configuration if you have to edit a file instead of a > > python script. > > > > I could, but currently we don't have a good place to put that for the > client. So I agree that the template file is nicer, but unless you fell > this is very important I'd rather not spend the time doing it. It's nice to be able to add a custom package that provide the "right" ntp.conf file for your setup. Maybe we can add instead an option to point to a different template? Anyway I guess we can have /usr/share/ipa on the client as well, would that be a problem? > > > Configure ipa servers as an ntp server and clients > > > to (by default) us the ipa server as an ntp server. > > > > I think we should do an ntpdate before starting ntp to make sure the > > clock is correctly synchronized before starting the daemon. > > if the skew is too big ntpd will not be able to compensate otherwise. > > > > Ok - I'll send another patch that does this. Thanks. Simo. From kmacmill at redhat.com Fri Nov 2 15:19:39 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Fri, 02 Nov 2007 11:19:39 -0400 Subject: [Freeipa-devel] [PATCH] NTP configuration for client and server In-Reply-To: <1194016383.12404.32.camel@localhost.localdomain> References: <919346fa283e74afc386.1193945709@cage.mentalrootkit.com> <1193947325.12404.26.camel@localhost.localdomain> <1194011302.4611.5.camel@localhost.localdomain> <1194016383.12404.32.camel@localhost.localdomain> Message-ID: <1194016779.4611.75.camel@localhost.localdomain> On Fri, 2007-11-02 at 11:13 -0400, Simo Sorce wrote: > On Fri, 2007-11-02 at 09:48 -0400, Karl MacMillan wrote: > > On Thu, 2007-11-01 at 16:02 -0400, Simo Sorce wrote: > > > On Thu, 2007-11-01 at 15:35 -0400, Karl MacMillan wrote: > > > > NTP configuration for client and server. > > > > > > Can you put the ntp.conf template in a file, it makes it much easier to > > > customize the configuration if you have to edit a file instead of a > > > python script. > > > > > > > I could, but currently we don't have a good place to put that for the > > client. So I agree that the template file is nicer, but unless you fell > > this is very important I'd rather not spend the time doing it. > > It's nice to be able to add a custom package that provide the "right" > ntp.conf file for your setup. Maybe we can add instead an option to > point to a different template? > Anyway I guess we can have /usr/share/ipa on the client as well, would > that be a problem? > I would want to put it in /usr/share/ipa/client to avoid two packages spamming the same directory. Of course, that means that neither package owns /usr/share/ipa (which I guess is already the case). And by custom package, do you mean a separate package from freeipa-client or a rebuilt package. A separate package wouldn't work because it could overwrite the existing template and if you rebuild the package you can change the python. Any packaging experts have opinions on this? Basically - I agree with the goal, I just don't think we have time right now. Karl From rcritten at redhat.com Fri Nov 2 15:34:48 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Nov 2007 11:34:48 -0400 Subject: [Freeipa-devel] [PATCH] make all should work Message-ID: <472B4398.1030901@redhat.com> The top level 'make all' doesn't currently work. This patch does it in a clumsy way by depending on autogen.sh but not re-running it every time you want to do a 'make'. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-346-makeall.patch Type: text/x-patch Size: 1136 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 Fri Nov 2 15:36:42 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Nov 2007 11:36:42 -0400 Subject: [Freeipa-devel] [PATCH] make UI group search work again Message-ID: <472B440A.1070800@redhat.com> Group search broke with the memberof search. The first element returned is the # of items in the list, we need to skip that. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-347-groups.patch Type: text/x-patch Size: 886 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 Fri Nov 2 15:44:34 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Nov 2007 11:44:34 -0400 Subject: [Freeipa-devel] [PATCH] show inactive users in the GUI search Message-ID: <472B45E2.5060400@redhat.com> Distinguish between active and inactive users on the Find People page. This is done by looping through the search list twice, once to display the active users and once to display the inactive users who will show with a silver background for now (in CSS so easily changed). This addresses trac #11. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-358-inactive.patch Type: text/x-patch Size: 2889 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 Nov 2 15:52:10 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 02 Nov 2007 11:52:10 -0400 Subject: [Freeipa-devel] [PATCH] NTP configuration for client and server In-Reply-To: <1194016779.4611.75.camel@localhost.localdomain> References: <919346fa283e74afc386.1193945709@cage.mentalrootkit.com> <1193947325.12404.26.camel@localhost.localdomain> <1194011302.4611.5.camel@localhost.localdomain> <1194016383.12404.32.camel@localhost.localdomain> <1194016779.4611.75.camel@localhost.localdomain> Message-ID: <1194018730.12404.50.camel@localhost.localdomain> On Fri, 2007-11-02 at 11:19 -0400, Karl MacMillan wrote: > On Fri, 2007-11-02 at 11:13 -0400, Simo Sorce wrote: > > On Fri, 2007-11-02 at 09:48 -0400, Karl MacMillan wrote: > > > On Thu, 2007-11-01 at 16:02 -0400, Simo Sorce wrote: > > > > On Thu, 2007-11-01 at 15:35 -0400, Karl MacMillan wrote: > > > > > NTP configuration for client and server. > > > > > > > > Can you put the ntp.conf template in a file, it makes it much easier to > > > > customize the configuration if you have to edit a file instead of a > > > > python script. > > > > > > > > > > I could, but currently we don't have a good place to put that for the > > > client. So I agree that the template file is nicer, but unless you fell > > > this is very important I'd rather not spend the time doing it. > > > > It's nice to be able to add a custom package that provide the "right" > > ntp.conf file for your setup. Maybe we can add instead an option to > > point to a different template? > > Anyway I guess we can have /usr/share/ipa on the client as well, would > > that be a problem? > > > > I would want to put it in /usr/share/ipa/client to avoid two packages > spamming the same directory. Of course, that means that neither package > owns /usr/share/ipa (which I guess is already the case). > > And by custom package, do you mean a separate package from > freeipa-client or a rebuilt package. A separate package wouldn't work > because it could overwrite the existing template and if you rebuild the > package you can change the python. > > Any packaging experts have opinions on this? > > Basically - I agree with the goal, I just don't think we have time right > now. Just open a ticket for a following release so we don't forget, let's go on, now. (The solution is to probably put it in /etc/ipa/templates and mark them as configuration, so a different package can just modify it or something like that. Asking people to modify python is not something I like). Simo. From rcritten at redhat.com Fri Nov 2 15:52:39 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Nov 2007 11:52:39 -0400 Subject: [Freeipa-devel] things to be stored Message-ID: <472B47C7.8030106@redhat.com> I could care less how the configuration is stored in LDAP, either as a extensibleObject or with its own schema, but here is the stuff I need stored somewhere: userSearchFields, a list of attributes e.g. uid,givenName,sn,telephoneNumber,ou,title searchTimeLimit, an integer, e.g. 2 customFields, a set of tuple of the form (label, attribute, required). All are strings. required is a boolean but will contain "true" or "false". This needs to be extensible as at some point we'll add a validator as well, and who knows what else, maybe things to limit field length, min/max size, etc. The current hardcoded version, in python, looks like: schema = [ { 'label': 'See Also', 'field': 'seeAlso', 'required': 'true', } , { 'label': 'O O O', 'field': 'o', 'required': 'false', } , ] Another thing we need to think about is how I'll fetch this from the server. Currently all requests to the server need to be authenticated but it would probably be better performance-wise to grab this at startup time. So should we allow unauthenticated requests to the XML-RPC interface? Currently the whole thing requires SSL and kerberos. 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 Fri Nov 2 16:59:38 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 02 Nov 2007 12:59:38 -0400 Subject: [Freeipa-devel] things to be stored In-Reply-To: <472B47C7.8030106@redhat.com> References: <472B47C7.8030106@redhat.com> Message-ID: <1194022778.21823.38.camel@localhost.localdomain> On Fri, 2007-11-02 at 11:52 -0400, Rob Crittenden wrote: > I could care less how the configuration is stored in LDAP, either as a > extensibleObject or with its own schema, but here is the stuff I need > stored somewhere: > > userSearchFields, a list of attributes e.g. > uid,givenName,sn,telephoneNumber,ou,title Do this need to be ordered? Or will a multivalued attribute suffices? > searchTimeLimit, an integer, e.g. 2 > > customFields, a set of tuple of the form (label, attribute, required). > All are strings. required is a boolean but will contain "true" or > "false". This needs to be extensible as at some point we'll add a > validator as well, and who knows what else, maybe things to limit field > length, min/max size, etc. > > The current hardcoded version, in python, looks like: > > schema = [ > { 'label': 'See Also', > 'field': 'seeAlso', > 'required': 'true', } , > { 'label': 'O O O', > 'field': 'o', > 'required': 'false', } , > ] ok all these strings seem to have a well defined syntax, can you do it with a multivalued attribute like? IpaGuiCustomField: See Also$seeAlso$true IpaGuiCustomField: My attribute$myAttr$false Do they need to be ordered? can $ be a valid value in a Label ? > Another thing we need to think about is how I'll fetch this from the > server. Currently all requests to the server need to be authenticated > but it would probably be better performance-wise to grab this at startup > time. So should we allow unauthenticated requests to the XML-RPC > interface? Currently the whole thing requires SSL and kerberos. The server itslef accepts anonymous connections, so we have 2 options I guess: 1) let's permit anonymous searches on the IPA GUI conf container 2) let's give turbogear a keytab (it can probably just use the apache keytab anyway) to access this information. Simo. From jonstanley at gmail.com Fri Nov 2 17:06:17 2007 From: jonstanley at gmail.com (Jon Stanley) Date: Fri, 2 Nov 2007 13:06:17 -0400 Subject: [Freeipa-devel] things to be stored In-Reply-To: <1194022778.21823.38.camel@localhost.localdomain> References: <472B47C7.8030106@redhat.com> <1194022778.21823.38.camel@localhost.localdomain> Message-ID: On 11/2/07, Simo Sorce wrote: > > The current hardcoded version, in python, looks like: > > > > schema = [ > > { 'label': 'See Also', > > 'field': 'seeAlso', > > 'required': 'true', } , > > { 'label': 'O O O', > > 'field': 'o', > > 'required': 'false', } , > > ] That was another one of my UI questions - why is 'See Also' required? What are you supposed to put there? I assume that these get populated into LDAP attributes? From rcritten at redhat.com Fri Nov 2 17:11:53 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Nov 2007 13:11:53 -0400 Subject: [Freeipa-devel] things to be stored In-Reply-To: <1194022778.21823.38.camel@localhost.localdomain> References: <472B47C7.8030106@redhat.com> <1194022778.21823.38.camel@localhost.localdomain> Message-ID: <472B5A59.2070403@redhat.com> Simo Sorce wrote: > On Fri, 2007-11-02 at 11:52 -0400, Rob Crittenden wrote: >> I could care less how the configuration is stored in LDAP, either as a >> extensibleObject or with its own schema, but here is the stuff I need >> stored somewhere: >> >> userSearchFields, a list of attributes e.g. >> uid,givenName,sn,telephoneNumber,ou,title > > Do this need to be ordered? Or will a multivalued attribute suffices? I don't think ordering matters. I'm just going to pass this to search_s(). >> searchTimeLimit, an integer, e.g. 2 >> >> customFields, a set of tuple of the form (label, attribute, required). >> All are strings. required is a boolean but will contain "true" or >> "false". This needs to be extensible as at some point we'll add a >> validator as well, and who knows what else, maybe things to limit field >> length, min/max size, etc. >> >> The current hardcoded version, in python, looks like: >> >> schema = [ >> { 'label': 'See Also', >> 'field': 'seeAlso', >> 'required': 'true', } , >> { 'label': 'O O O', >> 'field': 'o', >> 'required': 'false', } , >> ] > > ok all these strings seem to have a well defined syntax, can you do it > with a multivalued attribute like? > IpaGuiCustomField: See Also$seeAlso$true > IpaGuiCustomField: My attribute$myAttr$false > > Do they need to be ordered? > can $ be a valid value in a Label ? I think we should assume that ordering matters here. We can probably use whatever separate we want. I can URL-encode the individual components for safety. I can see someone putting a $ field though, perhaps "Salary $"? >> Another thing we need to think about is how I'll fetch this from the >> server. Currently all requests to the server need to be authenticated >> but it would probably be better performance-wise to grab this at startup >> time. So should we allow unauthenticated requests to the XML-RPC >> interface? Currently the whole thing requires SSL and kerberos. > > The server itslef accepts anonymous connections, so we have 2 options I > guess: > 1) let's permit anonymous searches on the IPA GUI conf container > 2) let's give turbogear a keytab (it can probably just use the apache > keytab anyway) to access this information. We don't want any special sauce that only our web-gui can use. Every interface needs to be public if at all possible (so others can dump our GUI if they want and have the same capabilities). And for a little more info. If we have an unauthenticated URI it means I'll need to make another XML-RPC listener. Not a huge deal but it will be some work. If this stuff is only read on start-up it means that web interface needs to be restarted when changes are made. Is it acceptable to simply retrieve this each time? 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 Nov 2 17:12:34 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Nov 2007 13:12:34 -0400 Subject: [Freeipa-devel] things to be stored In-Reply-To: References: <472B47C7.8030106@redhat.com> <1194022778.21823.38.camel@localhost.localdomain> Message-ID: <472B5A82.2050806@redhat.com> Jon Stanley wrote: > On 11/2/07, Simo Sorce wrote: > >>> The current hardcoded version, in python, looks like: >>> >>> schema = [ >>> { 'label': 'See Also', >>> 'field': 'seeAlso', >>> 'required': 'true', } , >>> { 'label': 'O O O', >>> 'field': 'o', >>> 'required': 'false', } , >>> ] > > That was another one of my UI questions - why is 'See Also' required? > What are you supposed to put there? I assume that these get populated > into LDAP attributes? We can probabably disable that. It is just a demonstration of custom fields. 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 prowley at redhat.com Fri Nov 2 17:45:45 2007 From: prowley at redhat.com (Pete Rowley) Date: Fri, 02 Nov 2007 10:45:45 -0700 Subject: [Freeipa-devel] things to be stored In-Reply-To: <472B5A59.2070403@redhat.com> References: <472B47C7.8030106@redhat.com> <1194022778.21823.38.camel@localhost.localdomain> <472B5A59.2070403@redhat.com> Message-ID: <472B6249.20209@redhat.com> Rob Crittenden wrote: > If this stuff is only read on start-up it means that web interface > needs to be restarted when changes are made. Is it acceptable to > simply retrieve this each time? I don't think we should do that. How about grabbing it the first time you need it? Doing that leaves us room for adding an online refresh of configuration. -- Pete -------------- 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 Nov 2 17:54:04 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 02 Nov 2007 13:54:04 -0400 Subject: [Freeipa-devel] things to be stored In-Reply-To: <472B5A59.2070403@redhat.com> References: <472B47C7.8030106@redhat.com> <1194022778.21823.38.camel@localhost.localdomain> <472B5A59.2070403@redhat.com> Message-ID: <1194026044.21823.58.camel@localhost.localdomain> On Fri, 2007-11-02 at 13:11 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > The server itslef accepts anonymous connections, so we have 2 options I > > guess: > > 1) let's permit anonymous searches on the IPA GUI conf container > > 2) let's give turbogear a keytab (it can probably just use the apache > > keytab anyway) to access this information. > > We don't want any special sauce that only our web-gui can use. Every > interface needs to be public if at all possible (so others can dump our > GUI if they want and have the same capabilities). Not proposing any special sauce here, this should be available to all as you say.. > And for a little more info. > > If we have an unauthenticated URI it means I'll need to make another > XML-RPC listener. Not a huge deal but it will be some work. I guess you can use the apache keytab when needed then. > If this stuff is only read on start-up it means that web interface needs > to be restarted when changes are made. Is it acceptable to simply > retrieve this each time? It depends what it means each time. Any chance we can do a time based caching? Retrieve it every 5 minutes or so if there are requests? Does it make any simpler ? Simo. From kmacmill at redhat.com Fri Nov 2 18:54:24 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Fri, 02 Nov 2007 14:54:24 -0400 Subject: [Freeipa-devel] [PATCH] NTP configuration for client and server In-Reply-To: <1194018730.12404.50.camel@localhost.localdomain> References: <919346fa283e74afc386.1193945709@cage.mentalrootkit.com> <1193947325.12404.26.camel@localhost.localdomain> <1194011302.4611.5.camel@localhost.localdomain> <1194016383.12404.32.camel@localhost.localdomain> <1194016779.4611.75.camel@localhost.localdomain> <1194018730.12404.50.camel@localhost.localdomain> Message-ID: <1194029664.17343.14.camel@mahler.iad.redhat.com> On Fri, 2007-11-02 at 11:52 -0400, Simo Sorce wrote: > On Fri, 2007-11-02 at 11:19 -0400, Karl MacMillan wrote: > > On Fri, 2007-11-02 at 11:13 -0400, Simo Sorce wrote: > > > On Fri, 2007-11-02 at 09:48 -0400, Karl MacMillan wrote: > > > > On Thu, 2007-11-01 at 16:02 -0400, Simo Sorce wrote: > > > > > On Thu, 2007-11-01 at 15:35 -0400, Karl MacMillan wrote: > > > > > > NTP configuration for client and server. > > > > > > > > > > Can you put the ntp.conf template in a file, it makes it much easier to > > > > > customize the configuration if you have to edit a file instead of a > > > > > python script. > > > > > > > > > > > > > I could, but currently we don't have a good place to put that for the > > > > client. So I agree that the template file is nicer, but unless you fell > > > > this is very important I'd rather not spend the time doing it. > > > > > > It's nice to be able to add a custom package that provide the "right" > > > ntp.conf file for your setup. Maybe we can add instead an option to > > > point to a different template? > > > Anyway I guess we can have /usr/share/ipa on the client as well, would > > > that be a problem? > > > > > > > I would want to put it in /usr/share/ipa/client to avoid two packages > > spamming the same directory. Of course, that means that neither package > > owns /usr/share/ipa (which I guess is already the case). > > > > And by custom package, do you mean a separate package from > > freeipa-client or a rebuilt package. A separate package wouldn't work > > because it could overwrite the existing template and if you rebuild the > > package you can change the python. > > > > Any packaging experts have opinions on this? > > > > Basically - I agree with the goal, I just don't think we have time right > > now. > > Just open a ticket for a following release so we don't forget, let's go > on, now. > (The solution is to probably put it in /etc/ipa/templates and mark them > as configuration, so a different package can just modify it or something > like that. > Asking people to modify python is not something I like). > Agreed - ticket #77. Karl From kmacmill at redhat.com Fri Nov 2 18:56:12 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Fri, 02 Nov 2007 14:56:12 -0400 Subject: [Freeipa-devel] [PATCH] NTP configuration for client and server In-Reply-To: <919346fa283e74afc386.1193945709@cage.mentalrootkit.com> References: <919346fa283e74afc386.1193945709@cage.mentalrootkit.com> Message-ID: <1194029772.17343.16.camel@mahler.iad.redhat.com> On Thu, 2007-11-01 at 15:35 -0400, Karl MacMillan wrote: > # HG changeset patch > # User "Karl MacMillan " > # Date 1193945702 14400 > # Node ID 919346fa283e74afc386a46b7ec3e6f27af4af12 > # Parent c0f72de1e5d83c8536a46c193989b78609506c29 > NTP configuration for client and server. > > Configure ipa servers as an ntp server and clients > to (by default) us the ipa server as an ntp server. > > Also corrected the messages about which ports should > be opened. > Pushed - I still owe a patch to call ntpdate. Karl From kmacmill at redhat.com Fri Nov 2 18:56:56 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Fri, 02 Nov 2007 14:56:56 -0400 Subject: [Freeipa-devel] [PATCH] make UI group search work again In-Reply-To: <472B440A.1070800@redhat.com> References: <472B440A.1070800@redhat.com> Message-ID: <1194029816.17343.18.camel@mahler.iad.redhat.com> On Fri, 2007-11-02 at 11:36 -0400, Rob Crittenden wrote: > Group search broke with the memberof search. The first element returned > is the # of items in the list, we need to skip that. > Pushed. Karl From kmacmill at redhat.com Fri Nov 2 18:57:32 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Fri, 02 Nov 2007 14:57:32 -0400 Subject: [Freeipa-devel] [PATCH] make all should work In-Reply-To: <472B4398.1030901@redhat.com> References: <472B4398.1030901@redhat.com> Message-ID: <1194029852.17343.20.camel@mahler.iad.redhat.com> On Fri, 2007-11-02 at 11:34 -0400, Rob Crittenden wrote: > The top level 'make all' doesn't currently work. This patch does it in a > clumsy way by depending on autogen.sh but not re-running it every time > you want to do a 'make'. > Pushed. Karl From kmacmill at redhat.com Fri Nov 2 18:58:43 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Fri, 02 Nov 2007 14:58:43 -0400 Subject: [Freeipa-devel] [PATCH] show inactive users in the GUI search In-Reply-To: <472B45E2.5060400@redhat.com> References: <472B45E2.5060400@redhat.com> Message-ID: <1194029923.17343.22.camel@mahler.iad.redhat.com> On Fri, 2007-11-02 at 11:44 -0400, Rob Crittenden wrote: > Distinguish between active and inactive users on the Find People page. > > This is done by looping through the search list twice, once to display > the active users and once to display the inactive users who will show > with a silver background for now (in CSS so easily changed). > > This addresses trac #11. > Pushed. Karl From jdennis at redhat.com Fri Nov 2 20:54:15 2007 From: jdennis at redhat.com (John Dennis) Date: Fri, 02 Nov 2007 16:54:15 -0400 Subject: [Freeipa-devel] status of radius IPA work Message-ID: <472B8E77.4020705@redhat.com> Phew, this has been a long week, I've made progress. The radius server is now able to perform a SASL bind to the IPA LDAP server using kerberos tickets obtained during the IPA install. Radiusd is can also successfully perform LDAP queries. The major components of the work thus far have been: * authored radiusinstance.py which does the following: - installs a radius LDAP schema in the slapd instance - generates and installs the radiusd configuration file - generates and installs the kerberos radius service keytab - starts and stops the radiusd server * Modified the radius ldap module: - modified the autotool files to add configuration options for building with SASL2 and KRB5, these can be toggled on or off separately and the locations of the header files can be specified (often necessary because many distributions install these components in alternate locations or co-install different versions. All code additions properly #ifdef'ed by symbols defined by configure. Proper autotool support will be necessary for upstream acceptance. - added support for new options in the radiusd configuration file to handle ldap sasl and krb parameters. - added struct (object) to group all kerberos values into an 'instance' - added code to acquire the kerberos service ticket, track it's expiration, and use it to perform a bind to the IPA LDAP server. - all code does proper initialization, shutdown with freeing and destroying of resources, debug tracing, and error handling in the context of the freeradius code. * Successfully tested running the radius server in the IPA environment with radiusd doing a sasl bind to the IPA LDAP and retrieving attributes. Next work items: * Complete the implementation of the ipa command line tool used to modify the radius per user attributes in LDAP (so far I've been using ldapmodify and ldif files). This will call through the XMLRPC to perform the ldap modifications and queries. Comments: Getting the radius to the point of performing a SASL bind against IPA was much more work than I originally anticipated. There was also considerable work with properly integrating the changes. I had hoped to have had that working by Wednesday with the IPA command line work completed by today. That work took 2 more days than I expected, the command line work won't being in earnest until Monday. Even when you think you know a technology you get humbled by the problems that you didn't anticipate, such was some of the kerberos hurdles I had to overcome this week. Generally I'm pretty satisfied with the progress so far. By the middle of next week I think we'll be in a position to start testing against a VPN concentrator. But don't be fooled, there is still plenty of work ahead :-) Note: None of the work to date or anticipated in the immediate future has addressed the issue of other authentication methods used by radius and whether we have the correct password hashes. Addressing those issues are not necessary to get to the point of testing VPN. -- John Dennis From rcritten at redhat.com Fri Nov 2 21:42:14 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Nov 2007 17:42:14 -0400 Subject: [Freeipa-devel] [PATCH] implement self-service Message-ID: <472B99B6.9040105@redhat.com> Define Self-Service as editting your own record. This has the side-effect of removing the realm from 'Logged in as' in the GUI. This can be changed by using user_name instead of display_name in master.kid. Might be less confusing this way anyhow. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-364-self.patch Type: text/x-patch Size: 3392 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 prowley at redhat.com Fri Nov 2 22:56:10 2007 From: prowley at redhat.com (Pete Rowley) Date: Fri, 02 Nov 2007 15:56:10 -0700 Subject: [Freeipa-devel] [PATCH] configure referential integrity plugin Message-ID: <472BAB0A.5000802@redhat.com> -- Pete -------------- 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 jdennis at redhat.com Sat Nov 3 17:59:30 2007 From: jdennis at redhat.com (John Dennis) Date: Sat, 03 Nov 2007 13:59:30 -0400 Subject: [Freeipa-devel] [PATCH] Initial Radius Work Message-ID: <472CB702.4090405@redhat.com> Attached are 3 mercurial changesets that comprise the initial work to integrate freeradius with IPA, please review. Question: It would be easier to review the patch if the diffs were cumulative rather than sequential (the last two changesets were minor issues discovered during a test install). Is there a way to get mecurial to roll up all the changes in a revision range into one diff? I couldn't figure out how to do it. Note: This comprises only the IPA source changes. There is also a significant change to the freeradius package in order to work with IPA. Sometime soon I'll build and post a new freeradius rpm. I wanted to get these initial changes out first for review ASAP. -- John Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: radius.patch Type: text/x-patch Size: 35746 bytes Desc: not available URL: From ssorce at redhat.com Sat Nov 3 19:37:13 2007 From: ssorce at redhat.com (Simo Sorce) Date: Sat, 03 Nov 2007 15:37:13 -0400 Subject: [Freeipa-devel] [PATCH] Initial Radius Work In-Reply-To: <472CB702.4090405@redhat.com> References: <472CB702.4090405@redhat.com> Message-ID: <1194118633.21823.61.camel@localhost.localdomain> On Sat, 2007-11-03 at 13:59 -0400, John Dennis wrote: > + # FIXME: ldap_server should be derived, not hardcoded to > localhost, also should it be a URL? > + radius.create_instance(realm_name, host_name, 'localhost') > + If at all possible, you should let ldap libraries use DNS discovery to find the ldap server, and not force one on them. this will allow automatic fallback eventually. Unells we want to tie a radiuserver to the local master for some other reasons, in which case you must use gethostname as you need the hostname of the server to get the right kerberos ticket. Simo. From jdennis at redhat.com Sat Nov 3 20:15:58 2007 From: jdennis at redhat.com (John Dennis) Date: Sat, 03 Nov 2007 16:15:58 -0400 Subject: [Freeipa-devel] [PATCH] Initial Radius Work In-Reply-To: <1194118633.21823.61.camel@localhost.localdomain> References: <472CB702.4090405@redhat.com> <1194118633.21823.61.camel@localhost.localdomain> Message-ID: <472CD6FE.9030608@redhat.com> Simo Sorce wrote: > On Sat, 2007-11-03 at 13:59 -0400, John Dennis wrote: >> + # FIXME: ldap_server should be derived, not hardcoded to >> localhost, also should it be a URL? >> + radius.create_instance(realm_name, host_name, 'localhost') >> + > > If at all possible, you should let ldap libraries use DNS discovery to > find the ldap server, and not force one on them. this will allow > automatic fallback eventually. Unells we want to tie a radiuserver to > the local master for some other reasons, in which case you must use > gethostname as you need the hostname of the server to get the right > kerberos ticket. > Sure, makes sense, but let me ask this then: The mechanism for discovery is IPADiscovery right? But, but that is used in an client, the code you called out is in a server install, albeit towards the end, will IPADiscovery work correctly this early on. e.g. before the server install completes? Also, if you look at funcs.py you'll see this: class IPAServer: def __init__(self): global _LDAPPool # FIXME, this needs to be auto-discovered self.host = 'localhost' self.port = 389 Should that be using IPADiscovery? -- John Dennis From ssorce at redhat.com Sun Nov 4 01:10:32 2007 From: ssorce at redhat.com (Simo Sorce) Date: Sat, 03 Nov 2007 21:10:32 -0400 Subject: [Freeipa-devel] [PATCH] Initial Radius Work In-Reply-To: <472CD6FE.9030608@redhat.com> References: <472CB702.4090405@redhat.com> <1194118633.21823.61.camel@localhost.localdomain> <472CD6FE.9030608@redhat.com> Message-ID: <1194138632.21823.65.camel@localhost.localdomain> On Sat, 2007-11-03 at 16:15 -0400, John Dennis wrote: > Simo Sorce wrote: > > On Sat, 2007-11-03 at 13:59 -0400, John Dennis wrote: > >> + # FIXME: ldap_server should be derived, not hardcoded to > >> localhost, also should it be a URL? > >> + radius.create_instance(realm_name, host_name, 'localhost') > >> + > > > > If at all possible, you should let ldap libraries use DNS discovery to > > find the ldap server, and not force one on them. this will allow > > automatic fallback eventually. Unells we want to tie a radiuserver to > > the local master for some other reasons, in which case you must use > > gethostname as you need the hostname of the server to get the right > > kerberos ticket. > > > > Sure, makes sense, but let me ask this then: > > The mechanism for discovery is IPADiscovery right? But, but that is used > in an client, the code you called out is in a server install, albeit > towards the end, will IPADiscovery work correctly this early on. e.g. > before the server install completes? No need ldap libraries can use DNS discovery by themselves as long as you do not provide a specific server name (AFAIK). > Also, if you look at funcs.py you'll see this: > > class IPAServer: > > def __init__(self): > global _LDAPPool > # FIXME, this needs to be auto-discovered > self.host = 'localhost' > self.port = 389 > > Should that be using IPADiscovery? It might just use dnsclient.py to search for the SRV record pointed to by the _ldap._tcp. DNS record, the whole IPADiscovery do a lot of checks that are not necessary for normal use. Simo. From rcritten at redhat.com Sun Nov 4 04:09:36 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Sun, 04 Nov 2007 00:09:36 -0400 Subject: [Freeipa-devel] [PATCH] Initial Radius Work In-Reply-To: <1194118633.21823.61.camel@localhost.localdomain> References: <472CB702.4090405@redhat.com> <1194118633.21823.61.camel@localhost.localdomain> Message-ID: <472D4600.7080909@redhat.com> Simo Sorce wrote: > On Sat, 2007-11-03 at 13:59 -0400, John Dennis wrote: >> + # FIXME: ldap_server should be derived, not hardcoded to >> localhost, also should it be a URL? >> + radius.create_instance(realm_name, host_name, 'localhost') >> + > > If at all possible, you should let ldap libraries use DNS discovery to > find the ldap server, and not force one on them. this will allow > automatic fallback eventually. Unells we want to tie a radiuserver to > the local master for some other reasons, in which case you must use > gethostname as you need the hostname of the server to get the right > kerberos ticket. > Well, considering that we do exactly the same thing throughout all the rest of IPA, I don't think this is really an issue. At this point it is a very safe assumption that the radius server IS installed on the same machine as FDS. This is, after all, in ipa-server-install which currently only does a bootstrap install of IPA. Perhaps a new bug needs to be filed to track this usage of localhost but I don't want to hold up John's patch for something we've all done. 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 Sun Nov 4 15:31:18 2007 From: ssorce at redhat.com (Simo Sorce) Date: Sun, 04 Nov 2007 10:31:18 -0500 Subject: [Freeipa-devel] [PATCH] configure referential integrity plugin In-Reply-To: <472BAB0A.5000802@redhat.com> References: <472BAB0A.5000802@redhat.com> Message-ID: <1194190278.21823.72.camel@localhost.localdomain> I see no patch attached .. Simo. From ssorce at redhat.com Sun Nov 4 15:34:39 2007 From: ssorce at redhat.com (Simo Sorce) Date: Sun, 04 Nov 2007 10:34:39 -0500 Subject: [Freeipa-devel] [PATCH] Initial Radius Work In-Reply-To: <472D4600.7080909@redhat.com> References: <472CB702.4090405@redhat.com> <1194118633.21823.61.camel@localhost.localdomain> <472D4600.7080909@redhat.com> Message-ID: <1194190479.21823.74.camel@localhost.localdomain> On Sun, 2007-11-04 at 00:09 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Sat, 2007-11-03 at 13:59 -0400, John Dennis wrote: > >> + # FIXME: ldap_server should be derived, not hardcoded to > >> localhost, also should it be a URL? > >> + radius.create_instance(realm_name, host_name, 'localhost') > >> + > > > > If at all possible, you should let ldap libraries use DNS discovery to > > find the ldap server, and not force one on them. this will allow > > automatic fallback eventually. Unells we want to tie a radiuserver to > > the local master for some other reasons, in which case you must use > > gethostname as you need the hostname of the server to get the right > > kerberos ticket. > > > > Well, considering that we do exactly the same thing throughout all the > rest of IPA, I don't think this is really an issue. At this point it is > a very safe assumption that the radius server IS installed on the same > machine as FDS. > > This is, after all, in ipa-server-install which currently only does a > bootstrap install of IPA. > > Perhaps a new bug needs to be filed to track this usage of localhost but > I don't want to hold up John's patch for something we've all done. not holding, just making a note. it's ok for inclusion for me. Simo. From kmacmill at redhat.com Mon Nov 5 14:45:34 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Mon, 05 Nov 2007 09:45:34 -0500 Subject: [Freeipa-devel] status of radius IPA work In-Reply-To: <472B8E77.4020705@redhat.com> References: <472B8E77.4020705@redhat.com> Message-ID: <1194273934.505.18.camel@mahler.iad.redhat.com> On Fri, 2007-11-02 at 16:54 -0400, John Dennis wrote: > Phew, this has been a long week, I've made progress. > > The radius server is now able to perform a SASL bind to the IPA LDAP > server using kerberos tickets obtained during the IPA install. Radiusd > is can also successfully perform LDAP queries. The major components of > the work thus far have been: > > * authored radiusinstance.py which does the following: > - installs a radius LDAP schema in the slapd instance > - generates and installs the radiusd configuration file > - generates and installs the kerberos radius service keytab > - starts and stops the radiusd server > > * Modified the radius ldap module: > - modified the autotool files to add configuration options > for building with SASL2 and KRB5, these can be toggled on > or off separately and the locations of the header files > can be specified (often necessary because many distributions > install these components in alternate locations or co-install > different versions. > > All code additions properly #ifdef'ed by symbols defined by > configure. > > Proper autotool support will be necessary for upstream > acceptance. > > - added support for new options in the radiusd configuration file to > handle ldap sasl and krb parameters. > > - added struct (object) to group all kerberos values into an > 'instance' > > - added code to acquire the kerberos service ticket, track it's > expiration, and use it to perform a bind to the IPA LDAP server. > > - all code does proper initialization, shutdown with freeing and > destroying of resources, debug tracing, and error handling in the > context of the freeradius code. > When will you submit this work to freeradius? I'm wondering whether we will know if these changes are acceptable to upstream before freeipa v1. Karl From jdennis at redhat.com Mon Nov 5 15:08:57 2007 From: jdennis at redhat.com (John Dennis) Date: Mon, 05 Nov 2007 10:08:57 -0500 Subject: [Freeipa-devel] status of radius IPA work In-Reply-To: <1194273934.505.18.camel@mahler.iad.redhat.com> References: <472B8E77.4020705@redhat.com> <1194273934.505.18.camel@mahler.iad.redhat.com> Message-ID: <472F3209.4090103@redhat.com> Karl MacMillan wrote: > When will you submit this work to freeradius? I'm wondering whether we > will know if these changes are acceptable to upstream before freeipa v1. My expectation was to submit it after we demonstrated everything is working and that no regressions have been introduced into freeradius. Given the lead time to get upstream to evaluate and accept patches I tend to doubt this will occur prior to the v1 release. I don't think upstream wants to get half-baked patches and ask them to spend time on them, rather if upstream can be shown "here is a really cool use of your project which is demonstrated to work and here is a patch which is clean and robust" would you please take some of your limited time and evaluate it the likelyhood of a positive reception will be much greater. IMHO it's still too early to know what works, what doesn't, and what else might need to be tweaked. Note, the changes are to permit kerberos authentication in a ldap bind. Strictly speaking this is not necessary to getting IPA to work with freeradius, it means we would have to start writing passwords into configuration files, something we really don't want to be doing. -- John Dennis From jdennis at redhat.com Mon Nov 5 15:59:48 2007 From: jdennis at redhat.com (John Dennis) Date: Mon, 05 Nov 2007 10:59:48 -0500 Subject: [Freeipa-devel] new freeradius package for use with ipa Message-ID: <472F3DF4.2040807@redhat.com> Freeradius was updated with support for kerberos sasl binds in the rlm_ldap module. This version of freeradius should be used for testing. Karl: Please build the following rpm and add it to the downloads section of freeipa: http://people.redhat.com/jdennis/freeradius-1.1.7-3.2.ipa.fc8.src.rpm Thanks -- John Dennis From kmacmillan at redhat.com Mon Nov 5 15:29:13 2007 From: kmacmillan at redhat.com (Karl MacMillan) Date: Mon, 05 Nov 2007 11:29:13 -0400 Subject: [Freeipa-devel] [PATCH] Make it possible to force the running of autogen Message-ID: <48b7a619dec60bf2b72a.1194280153@mahler.iad.redhat.com> # HG changeset patch # User "Karl MacMillan " # Date 1194280068 18000 # Node ID 48b7a619dec60bf2b72a34d7fdc2ab7adad7c01d # Parent ceff443d46a3b3f64e7cd9ca4ae72758cd581ccd Make it possible to force the running of autogen. With the change to run autogen on make all if there was no makefile present, it became impossible to force the running of autogen when that is needed. Fix that by adding a bootstrap-autogen target that checks the existing of Makefiles and reverting the autogen target to always run autogen. diff -r ceff443d46a3 -r 48b7a619dec6 Makefile --- a/Makefile Fri Nov 02 11:42:38 2007 -0400 +++ b/Makefile Mon Nov 05 11:27:48 2007 -0500 @@ -35,14 +35,18 @@ CLI_TARBALL_PREFIX=$(PRJ_PREFIX)-client- CLI_TARBALL_PREFIX=$(PRJ_PREFIX)-client-$(CLI_VERSION) CLI_TARBALL=$(CLI_TARBALL_PREFIX).tgz -all: autogen +all: bootstrap-autogen @for subdir in $(SUBDIRS); do \ (cd $$subdir && $(MAKE) $@) || exit 1; \ done -autogen: +bootstrap-autogen: cd ipa-server; if [ ! -e Makefile ]; then ./autogen.sh --prefix=/usr --sysconfdir=/etc; fi cd ipa-client; if [ ! -e Makefile ]; then ./autogen.sh --prefix=/usr --sysconfdir=/etc; fi + +autogen: + cd ipa-server; ./autogen.sh --prefix=/usr --sysconfdir=/etc; + cd ipa-client; ./autogen.sh --prefix=/usr --sysconfdir=/etc; configure: cd ipa-server; ./configure --prefix=/usr --sysconfdir=/etc From kmacmillan at redhat.com Mon Nov 5 15:40:03 2007 From: kmacmillan at redhat.com (Karl MacMillan) Date: Mon, 05 Nov 2007 11:40:03 -0400 Subject: [Freeipa-devel] [PATCH] Prevent gzip from requesting confirmation Message-ID: <5a4b477d68ff5f26ea2d.1194280803@mahler.iad.redhat.com> # HG changeset patch # User "Karl MacMillan " # Date 1194280799 18000 # Node ID 5a4b477d68ff5f26ea2d445b83e5bf67f329df35 # Parent 48b7a619dec60bf2b72a34d7fdc2ab7adad7c01d Prevent gzip from requesting confirmation. The current manpage installation gzips the files in place and requests confirmation before overwriting existing files. Add -f to prevent prompting. We should consider not gzipping the files in place. diff -r 48b7a619dec6 -r 5a4b477d68ff ipa-admintools/man/Makefile --- a/ipa-admintools/man/Makefile Mon Nov 05 11:27:48 2007 -0500 +++ b/ipa-admintools/man/Makefile Mon Nov 05 11:39:59 2007 -0500 @@ -10,12 +10,12 @@ MANFILES=\ ipa-groupmod.1 \ ipa-passwd.1 \ ipa-usermod.1 - + all: ; install: mkdir -p $(MANDIR)/man1 - @for i in $(MANFILES) ; do install -m 644 $$i $(MANDIR)/man1 ; gzip $(MANDIR)/man1/$$i ; done + @for i in $(MANFILES) ; do install -m 644 $$i $(MANDIR)/man1 ; gzip -f $(MANDIR)/man1/$$i ; done clean: From kmacmillan at redhat.com Mon Nov 5 16:44:33 2007 From: kmacmillan at redhat.com (Karl MacMillan) Date: Mon, 05 Nov 2007 12:44:33 -0400 Subject: [Freeipa-devel] [PATCH] Introduce service base class and clean up ipa-server-install Message-ID: # HG changeset patch # User "Karl MacMillan " # Date 1194284670 18000 # Node ID db76e0233ab55b47ae226b2062a54c5a74441fe6 # Parent 5a4b477d68ff5f26ea2d445b83e5bf67f329df35 Introduce service base class and clean up ipa-server-install 1) Add a base class for all of the instance objects. 2) Normalize usage of logging. 3) General cleanups of ipa-server-install. 4) Make better use of httpinstance. 5) Add webguiinstance. 6) Improve progress reporting during installation. Works Here (TM), but it would be nice to get someone else to test since this moves code around a bit. diff -r 5a4b477d68ff -r db76e0233ab5 ipa-server/ipa-install/ipa-server-install --- a/ipa-server/ipa-install/ipa-server-install Mon Nov 05 11:39:59 2007 -0500 +++ b/ipa-server/ipa-install/ipa-server-install Mon Nov 05 12:44:30 2007 -0500 @@ -47,6 +47,9 @@ import ipaserver.bindinstance import ipaserver.bindinstance import ipaserver.httpinstance import ipaserver.ntpinstance +import ipaserver.webguiinstance + +from ipaserver import service from ipa.ipautil import run @@ -524,7 +527,11 @@ def main(): # Create a HTTP instance http = ipaserver.httpinstance.HTTPInstance() - http.create_instance() + http.create_instance(realm_name, host_name) + + # Create a Web Gui instance + webgui = ipaserver.webguiinstance.WebGuiInstance() + webgui.create_instance() bind.setup(host_name, ip_address, realm_name) if options.setup_bind: @@ -542,68 +549,15 @@ def main(): bind.create_sample_bind_zone() # Restart ds and krb after configurations have been changed + service.print_msg("restarting the directory server") ds.restart() + + service.print_msg("restarting the KDC") krb.restart() # Configure ntpd ntp = ipaserver.ntpinstance.NTPInstance() ntp.create_instance() - - try: - selinux=0 - try: - if (os.path.exists('/usr/sbin/selinuxenabled')): - run(["/usr/sbin/selinuxenabled"]) - selinux=1 - except subprocess.CalledProcessError, e: - # selinuxenabled returns 1 if not enabled - pass - - if selinux: - # Allow apache to connect to the turbogears web gui - # This can still fail even if selinux is enabled - try: - run(["/usr/sbin/setsebool", "-P", "httpd_can_network_connect", "true"]) - except: - print "WARNING: could not set selinux boolean httpd_can_network_connect to true." - print "The web interface may not function correctly until this boolean is" - print "successfully change with the command:" - print " /usr/sbin/setsebool -P httpd_can_network_connect true" - print "Try updating the policycoreutils and selinux-policy packages." - pass - - # Start the web gui - run(["/sbin/service", "ipa-webgui", "start"]) - - # Set the web gui to start on boot - run(["/sbin/chkconfig", "ipa-webgui", "on"]) - - # Restart apache - run(["/sbin/service", "httpd", "restart"]) - - # Set apache to start on boot - run(["/sbin/chkconfig", "httpd", "on"]) - - # Set fedora-ds to start on boot - run(["/sbin/chkconfig", "dirsrv", "on"]) - - # Set the KDC to start on boot - run(["/sbin/chkconfig", "krb5kdc", "on"]) - - # Set the Kpasswd to start on boot - run(["/sbin/chkconfig", "ipa-kpasswd", "on"]) - - # Start Kpasswd - run(["/sbin/service", "ipa-kpasswd", "start"]) - - # Set the ntpd to start on boot - run(["/sbin/chkconfig", "ntpd", "on"]) - - # Restart ntpd - run(["/sbin/service", "ntpd", "restart"]) - except subprocess.CalledProcessError, e: - print "Installation failed:", e - return 1 # Set the admin user kerberos password ds.change_admin_password(admin_password) diff -r 5a4b477d68ff -r db76e0233ab5 ipa-server/ipaserver/Makefile.am --- a/ipa-server/ipaserver/Makefile.am Mon Nov 05 11:39:59 2007 -0500 +++ b/ipa-server/ipaserver/Makefile.am Mon Nov 05 12:44:30 2007 -0500 @@ -9,6 +9,8 @@ app_PYTHON = \ krbinstance.py \ httpinstance.py \ ntpinstance.py \ + service.py \ + webguiinstance.py \ $(NULL) EXTRA_DIST = \ diff -r 5a4b477d68ff -r db76e0233ab5 ipa-server/ipaserver/dsinstance.py --- a/ipa-server/ipaserver/dsinstance.py Mon Nov 05 11:39:59 2007 -0500 +++ b/ipa-server/ipaserver/dsinstance.py Mon Nov 05 12:44:30 2007 -0500 @@ -24,7 +24,9 @@ import shutil import shutil import logging import pwd + from ipa.ipautil import * +import service SERVER_ROOT_64 = "/usr/lib64/dirsrv" SERVER_ROOT_32 = "/usr/lib/dirsrv" @@ -57,8 +59,9 @@ RootDNPwd= $PASSWORD RootDNPwd= $PASSWORD """ -class DsInstance: +class DsInstance(service.Service): def __init__(self): + service.Service.__init__(self, "dirsrv") self.serverid = None self.realm_name = None self.suffix = None @@ -75,6 +78,7 @@ class DsInstance: self.dm_password = dm_password self.__setup_sub_dict() + self.start_creation(10, "Configuring directory server:") self.__create_ds_user() self.__create_instance() self.__add_default_schemas() @@ -83,12 +87,18 @@ class DsInstance: self.__enable_ssl() self.__certmap_conf() try: + self.step("restarting directory server") self.restart() except: # TODO: roll back here? print "Failed to restart the ds instance" self.__add_default_layout() + self.step("configuring directoy to start on boot") + self.chkconfig_on() + + self.done_creation() + def config_dirname(self): if not self.serverid: raise RuntimeError("serverid not set") @@ -96,15 +106,6 @@ class DsInstance: def schema_dirname(self): return self.config_dirname() + "/schema/" - - def stop(self): - run(["/sbin/service", "dirsrv", "stop"]) - - def start(self): - run(["/sbin/service", "dirsrv", "start"]) - - def restart(self): - run(["/sbin/service", "dirsrv", "restart"]) def __setup_sub_dict(self): server_root = find_server_root() @@ -114,6 +115,7 @@ class DsInstance: SERVER_ROOT=server_root) def __create_ds_user(self): + self.step("creating directory server user") try: pwd.getpwnam(self.ds_user) logging.debug("ds user %s exists" % self.ds_user) @@ -124,11 +126,10 @@ class DsInstance: run(args) logging.debug("done adding user") except subprocess.CalledProcessError, e: - print "Failed to add user", e - logging.debug("failed to add user %s" % e) + logging.critical("failed to add user %s" % e) def __create_instance(self): - logging.debug("creating ds instance . . . ") + self.step("creating directory server instance") inf_txt = template_str(INF_TEMPLATE, self.sub_dict) logging.debug(inf_txt) inf_fd = write_tmp_file(inf_txt) @@ -143,33 +144,33 @@ class DsInstance: run(args) logging.debug("completed creating ds instance") except subprocess.CalledProcessError, e: - print "failed to restart ds instance", e - logging.debug("failed to restart ds instance %s" % e) + logging.critical("failed to create ds instance" % e) logging.debug("restarting ds instance") try: self.restart() logging.debug("done restarting ds instance") except subprocess.CalledProcessError, e: - print "failed to restart ds instance", e - logging.debug("failed to restart ds instance %s" % e) + logging.critical("failed to restart ds instance %s" % e) def __add_default_schemas(self): + self.step("adding default schema") shutil.copyfile(SHARE_DIR + "60kerberos.ldif", self.schema_dirname() + "60kerberos.ldif") shutil.copyfile(SHARE_DIR + "60samba.ldif", self.schema_dirname() + "60samba.ldif") def __add_memberof_module(self): + self.step("enabling memberof plugin") memberof_txt = template_file(SHARE_DIR + "memberof-conf.ldif", self.sub_dict) memberof_fd = write_tmp_file(memberof_txt) try: ldap_mod(memberof_fd, "cn=Directory Manager", self.dm_password) except subprocess.CalledProcessError, e: - print "Failed to load memberof-conf.ldif", e + logging.critical("Failed to load memberof-conf.ldif: %s" % str(e)) memberof_fd.close() def __enable_ssl(self): - logging.debug("configuring ssl for ds instance") + self.step("enabling ssl") dirname = self.config_dirname() args = ["/usr/share/ipa/ipa-server-setupssl", self.dm_password, dirname, self.host_name] @@ -177,13 +178,13 @@ class DsInstance: run(args) logging.debug("done configuring ssl for ds instance") except subprocess.CalledProcessError, e: - print "Failed to enable ssl in ds instance", e - logging.debug("Failed to configure ssl in ds instance %s" % e) + logging.critical("Failed to configure ssl in ds instance %s" % e) def __add_default_layout(self): + self.step("adding default layout") txt = template_file(SHARE_DIR + "bootstrap-template.ldif", self.sub_dict) inf_fd = write_tmp_file(txt) - logging.debug("adding default ds layout") + logging.debug("adding default dfrom ipa.ipautil import *s layout") args = ["/usr/bin/ldapmodify", "-xv", "-D", "cn=Directory Manager", "-w", self.dm_password, "-f", inf_fd.name] try: @@ -191,9 +192,10 @@ class DsInstance: logging.debug("done adding default ds layout") except subprocess.CalledProcessError, e: print "Failed to add default ds layout", e - logging.debug("Failed to add default ds layout %s" % e) + logging.critical("Failed to add default ds layout %s" % e) def __create_indeces(self): + self.step("creating indeces") txt = template_file(SHARE_DIR + "indeces.ldif", self.sub_dict) inf_fd = write_tmp_file(txt) logging.debug("adding/updating indeces") @@ -203,17 +205,15 @@ class DsInstance: run(args) logging.debug("done adding/updating indeces") except subprocess.CalledProcessError, e: - print "Failed to add default ds layout", e - logging.debug("Failed to add/update indeces %s" % e) + logging.critical("Failed to add/update indeces %s" % str(e)) def __certmap_conf(self): - logging.debug("configuring certmap.conf for ds instance") + self.step("configuring certmap.conf") dirname = self.config_dirname() certmap_conf = template_file(SHARE_DIR+"certmap.conf.template", self.sub_dict) certmap_fd = open(dirname+"certmap.conf", "w+") certmap_fd.write(certmap_conf) certmap_fd.close() - logging.debug("done configuring certmap.conf for ds instance") def change_admin_password(self, password): logging.debug("Changing admin password") diff -r 5a4b477d68ff -r db76e0233ab5 ipa-server/ipaserver/httpinstance.py --- a/ipa-server/ipaserver/httpinstance.py Mon Nov 05 11:39:59 2007 -0500 +++ b/ipa-server/ipaserver/httpinstance.py Mon Nov 05 12:44:30 2007 -0500 @@ -20,16 +20,25 @@ import subprocess import subprocess import string import tempfile -import shutil import logging import pwd -from ipa.ipautil import * import fileinput import sys +import time + +import service +from ipa.ipautil import * HTTPD_DIR = "/etc/httpd" SSL_CONF = HTTPD_DIR + "/conf.d/ssl.conf" NSS_CONF = HTTPD_DIR + "/conf.d/nss.conf" + +selinux_warning = """WARNING: could not set selinux boolean httpd_can_network_connect to true. +The web interface may not function correctly until this boolean is +successfully change with the command: + /usr/sbin/setsebool -P httpd_can_network_connect true +Try updating the policycoreutils and selinux-policy packages. +""" def update_file(filename, orig, subst): if os.path.exists(filename): @@ -42,35 +51,90 @@ def update_file(filename, orig, subst): sys.stdout.write(p.sub(subst, line)) fileinput.close() -class HTTPInstance: +class HTTPInstance(service.Service): def __init__(self): - pass + service.Service.__init__(self, "httpd") - def create_instance(self): + def create_instance(self, realm, fqdn): + self.sub_dict = { "REALM" : realm } + self.fqdn = fqdn + self.realm = realm + + self.start_creation(6, "Configuring the web interface") + self.__disable_mod_ssl() self.__set_mod_nss_port() + self.__configure_http() + self.__create_http_keytab() + + self.step("restarting httpd") + self.restart() + + self.step("configuring httpd to start on boot") + self.chkconfig_on() + + self.done_creation() + + def __selinux_config(self): + self.step("configuring SELinux for httpd") + selinux=0 try: - self.restart() - except: - # TODO: roll back here? - print "Failed to restart httpd" + if (os.path.exists('/usr/sbin/selinuxenabled')): + run(["/usr/sbin/selinuxenabled"]) + selinux=1 + except subprocess.CalledProcessError: + # selinuxenabled returns 1 if not enabled + pass - def stop(self): - run(["/sbin/service", "httpd", "stop"]) + if selinux: + # Allow apache to connect to the turbogears web gui + # This can still fail even if selinux is enabled + try: + run(["/usr/sbin/setsebool", "-P", "httpd_can_network_connect", "true"]) + except: + self.print_msg(selinux_warning) + + def __create_http_keytab(self): + self.step("creating a keytab for httpd") + try: + if file_exists("/etc/httpd/conf/ipa.keytab"): + os.remove("/etc/httpd/conf/ipa.keytab") + except os.error: + print "Failed to remove /etc/httpd/conf/ipa.keytab." + (kwrite, kread, kerr) = os.popen3("/usr/kerberos/sbin/kadmin.local") + kwrite.write("addprinc -randkey HTTP/"+self.fqdn+"@"+self.realm+"\n") + kwrite.flush() + kwrite.write("ktadd -k /etc/httpd/conf/ipa.keytab HTTP/"+self.fqdn+"@"+self.realm+"\n") + kwrite.flush() + kwrite.close() + kread.close() + kerr.close() - def start(self): - run(["/sbin/service", "httpd", "start"]) + # give kadmin time to actually write the file before we go on + retry = 0 + while not file_exists("/etc/httpd/conf/ipa.keytab"): + time.sleep(1) + retry += 1 + if retry > 15: + print "Error timed out waiting for kadmin to finish operations\n" + sys.exit(1) - def restart(self): - run(["/sbin/service", "httpd", "restart"]) + pent = pwd.getpwnam("apache") + os.chown("/etc/httpd/conf/ipa.keytab", pent.pw_uid, pent.pw_gid) + + def __configure_http(self): + self.step("configuring httpd") + http_txt = template_file(SHARE_DIR + "ipa.conf", self.sub_dict) + http_fd = open("/etc/httpd/conf.d/ipa.conf", "w") + http_fd.write(http_txt) + http_fd.close() + def __disable_mod_ssl(self): - logging.debug("disabling mod_ssl in httpd") + self.step("disabling mod_ssl in httpd") if os.path.exists(SSL_CONF): os.rename(SSL_CONF, "%s.moved_by_ipa" % SSL_CONF) - logging.debug("done disabling mod_ssl") def __set_mod_nss_port(self): - logging.debug("Setting mod_nss port to 443") + self.step("Setting mod_nss port to 443") update_file(NSS_CONF, '8443', '443') - logging.debug("done setting mod_nss port") diff -r 5a4b477d68ff -r db76e0233ab5 ipa-server/ipaserver/krbinstance.py --- a/ipa-server/ipaserver/krbinstance.py Mon Nov 05 11:39:59 2007 -0500 +++ b/ipa-server/ipaserver/krbinstance.py Mon Nov 05 12:44:30 2007 -0500 @@ -32,6 +32,8 @@ import pwd import pwd import socket import time + +import service from ipa.ipautil import * def host_to_domain(fqdn): @@ -63,8 +65,9 @@ def update_key_val_in_file(filename, key f.write("%s=%s\n" % (key, val)) f.close() -class KrbInstance: +class KrbInstance(service.Service): def __init__(self): + service.Service.__init__(self, "krb5kdc") self.ds_user = None self.fqdn = None self.realm = None @@ -95,39 +98,41 @@ class KrbInstance: # It could have been not running pass + self.start_creation(10, "Configuring Kerberos KDC") + self.__configure_kdc_account_password() self.__setup_sub_dict() self.__configure_ldap() - self.__configure_http() - self.__create_instance() self.__create_ds_keytab() - self.__create_http_keytab() - self.__export_kadmin_changepw_keytab() self.__add_pwd_extop_module() try: + self.step("starting the KDC") self.start() except: - print "krb5kdc service failed to start" - - def stop(self): - run(["/sbin/service", "krb5kdc", "stop"]) - - def start(self): - run(["/sbin/service", "krb5kdc", "start"]) - - def restart(self): - run(["/sbin/service", "krb5kdc", "restart"]) + logging.critical("krb5kdc service failed to start") + + self.step("configuring KDC to start on boot") + self.chkconfig_on() + + self.step("configuring ipa-kpasswd to start on boot") + service.chkconfig_on("ipa-kpasswd") + + self.step("starting ipa-kpasswd") + service.start("ipa-kpasswd") + + self.done_creation() def __configure_kdc_account_password(self): + self.step("setting KDC account password") hexpwd = '' for x in self.kdc_password: hexpwd += (hex(ord(x))[2:]) @@ -145,14 +150,14 @@ class KrbInstance: REALM=self.realm) def __configure_ldap(self): - + self.step("adding kerberos configuration to the directory") #TODO: test that the ldif is ok with any random charcter we may use in the password kerberos_txt = template_file(SHARE_DIR + "kerberos.ldif", self.sub_dict) kerberos_fd = write_tmp_file(kerberos_txt) try: ldap_mod(kerberos_fd, "cn=Directory Manager", self.admin_password) except subprocess.CalledProcessError, e: - print "Failed to load kerberos.ldif", e + logging.critical("Failed to load kerberos.ldif: %s" % str(e)) kerberos_fd.close() #Change the default ACL to avoid anonimous access to kerberos keys and othe hashes @@ -161,10 +166,11 @@ class KrbInstance: try: ldap_mod(aci_fd, "cn=Directory Manager", self.admin_password) except subprocess.CalledProcessError, e: - print "Failed to load default-aci.ldif", e + logging.critical("Failed to load default-aci.ldif: %s" % str(e)) aci_fd.close() def __create_instance(self): + self.step("configuring KDC") kdc_conf = template_file(SHARE_DIR+"kdc.conf.template", self.sub_dict) kdc_fd = open("/var/kerberos/krb5kdc/kdc.conf", "w+") kdc_fd.write(kdc_conf) @@ -200,12 +206,13 @@ class KrbInstance: #add the password extop module def __add_pwd_extop_module(self): + self.step("adding the password extenstion to the directory") extop_txt = template_file(SHARE_DIR + "pwd-extop-conf.ldif", self.sub_dict) extop_fd = write_tmp_file(extop_txt) try: ldap_mod(extop_fd, "cn=Directory Manager", self.admin_password) except subprocess.CalledProcessError, e: - print "Failed to load pwd-extop-conf.ldif", e + logging.critical("Failed to load pwd-extop-conf.ldif: %s" % str(e)) extop_fd.close() #add an ACL to let the DS user read the master key @@ -213,14 +220,15 @@ class KrbInstance: try: run(args) except subprocess.CalledProcessError, e: - print "Failed to set the ACL on the master key", e + logging.critical("Failed to set the ACL on the master key: %s" % str(e)) def __create_ds_keytab(self): + self.step("creating a keytab for the directory") try: if file_exists("/etc/dirsrv/ds.keytab"): os.remove("/etc/dirsrv/ds.keytab") except os.error: - print "Failed to remove /etc/dirsrv/ds.keytab." + logging.critical("Failed to remove /etc/dirsrv/ds.keytab.") (kwrite, kread, kerr) = os.popen3("/usr/kerberos/sbin/kadmin.local") kwrite.write("addprinc -randkey ldap/"+self.fqdn+"@"+self.realm+"\n") kwrite.flush() @@ -236,7 +244,7 @@ class KrbInstance: time.sleep(1) retry += 1 if retry > 15: - print "Error timed out waiting for kadmin to finish operations\n" + logging.critical("Error timed out waiting for kadmin to finish operations") sys.exit(1) update_key_val_in_file("/etc/sysconfig/dirsrv", "export KRB5_KTNAME", "/etc/dirsrv/ds.keytab") @@ -244,6 +252,7 @@ class KrbInstance: os.chown("/etc/dirsrv/ds.keytab", pent.pw_uid, pent.pw_gid) def __export_kadmin_changepw_keytab(self): + self.step("exporting the kadmin keytab") (kwrite, kread, kerr) = os.popen3("/usr/kerberos/sbin/kadmin.local") kwrite.write("modprinc +requires_preauth kadmin/changepw\n") kwrite.flush() @@ -264,42 +273,11 @@ class KrbInstance: time.sleep(1) retry += 1 if retry > 15: - print "Error timed out waiting for kadmin to finish operations\n" + logging.critical("Error timed out waiting for kadmin to finish operations") sys.exit(1) update_key_val_in_file("/etc/sysconfig/ipa-kpasswd", "export KRB5_KTNAME", "/var/kerberos/krb5kdc/kpasswd.keytab") pent = pwd.getpwnam(self.ds_user) os.chown("/var/kerberos/krb5kdc/kpasswd.keytab", pent.pw_uid, pent.pw_gid) - def __create_http_keytab(self): - try: - if file_exists("/etc/httpd/conf/ipa.keytab"): - os.remove("/etc/httpd/conf/ipa.keytab") - except os.error: - print "Failed to remove /etc/httpd/conf/ipa.keytab." - (kwrite, kread, kerr) = os.popen3("/usr/kerberos/sbin/kadmin.local") - kwrite.write("addprinc -randkey HTTP/"+self.fqdn+"@"+self.realm+"\n") - kwrite.flush() - kwrite.write("ktadd -k /etc/httpd/conf/ipa.keytab HTTP/"+self.fqdn+"@"+self.realm+"\n") - kwrite.flush() - kwrite.close() - kread.close() - kerr.close() - - # give kadmin time to actually write the file before we go on - retry = 0 - while not file_exists("/etc/httpd/conf/ipa.keytab"): - time.sleep(1) - retry += 1 - if retry > 15: - print "Error timed out waiting for kadmin to finish operations\n" - sys.exit(1) - - pent = pwd.getpwnam("apache") - os.chown("/etc/httpd/conf/ipa.keytab", pent.pw_uid, pent.pw_gid) - - def __configure_http(self): - http_txt = template_file(SHARE_DIR + "ipa.conf", self.sub_dict) - http_fd = open("/etc/httpd/conf.d/ipa.conf", "w") - http_fd.write(http_txt) - http_fd.close() + diff -r 5a4b477d68ff -r db76e0233ab5 ipa-server/ipaserver/ntpinstance.py --- a/ipa-server/ipaserver/ntpinstance.py Mon Nov 05 11:39:59 2007 -0500 +++ b/ipa-server/ipaserver/ntpinstance.py Mon Nov 05 12:44:30 2007 -0500 @@ -20,8 +20,16 @@ from ipa.ipautil import * from ipa.ipautil import * import shutil -class NTPInstance: +import service + +class NTPInstance(service.Service): + def __init__(self): + service.Service.__init__(self, "ntpd") + def create_instance(self): + self.start_creation(3, "Configuring ntpd") + + self.step("writing configuration") # The template sets the config to point towards ntp.pool.org, but # they request that software not point towards the default pool. # We use the OS variable to point it towards either the rhel @@ -48,3 +56,9 @@ class NTPInstance: # we might consider setting the date manually using ntpd -qg in case # the current time is very far off. + + self.step("starting ntpd") + self.start() + + self.step("configuring ntpd to start on boot") + self.chkconfig_on() diff -r 5a4b477d68ff -r db76e0233ab5 ipa-server/ipaserver/service.py --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/ipa-server/ipaserver/service.py Mon Nov 05 12:44:30 2007 -0500 @@ -0,0 +1,86 @@ +# Authors: Karl MacMillan +# +# Copyright (C) 2007 Red Hat +# see file 'COPYING' for use and warranty information +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; version 2 or later +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA +# + +from ipa.ipautil import * +import logging, sys + + +def stop(service_name): + run(["/sbin/service", service_name, "stop"]) + +def start(service_name): + run(["/sbin/service", service_name, "start"]) + +def restart(service_name): + run(["/sbin/service", service_name, "restart"]) + +def chkconfig_on(service_name): + run(["/sbin/chkconfig", service_name, "on"]) + +def chkconfig_off(service_name): + run(["/sbin/chkconfig", service_name, "off"]) + +def print_msg(message, output_fd=sys.stdout): + logging.debug(message) + output_fd.write(message) + output_fd.write("\n") + + +class Service: + def __init__(self, service_name): + self.service_name = service_name + self.num_steps = -1 + self.current_step = -1 + self.output_fd = sys.stdout + + def set_output(self, fd): + self.output_fd = fd + + def stop(self): + stop(self.service_name) + + def start(self): + start(self.service_name) + + def restart(self): + restart(self.service_name) + + def chkconfig_on(self): + chkconfig_on(self.service_name) + + def chkconfig_off(self): + chkconfig_off(self.service_name) + + def print_msg(self, message): + print_msg(message, self.output_fd) + + def start_creation(self, num_steps, message): + self.num_steps = num_steps + self.cur_step = 0 + self.print_msg(message) + + def step(self, message): + self.cur_step += 1 + self.print_msg("[%d/%d]: %s" % (self.cur_step, self.num_steps, message)) + + def done_creation(self): + self.cur_step = -1 + self.num_steps = -1 + self.print_msg("done configuring %s." % self.service_name) + diff -r 5a4b477d68ff -r db76e0233ab5 ipa-server/ipaserver/webguiinstance.py --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/ipa-server/ipaserver/webguiinstance.py Mon Nov 05 12:44:30 2007 -0500 @@ -0,0 +1,40 @@ +# Authors: Karl MacMillan +# +# Copyright (C) 2007 Red Hat +# see file 'COPYING' for use and warranty information +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; version 2 or later +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA +# + +import logging + +from ipa.ipautil import * +import service + +class WebGuiInstance(service.Service): + def __init__(self): + service.Service.__init__(self, "ipa-webgui") + + def create_instance(self): + self.start_creation(2, "Configuring ipa-webgui") + + self.step("starting ipa-webgui") + service.start("ipa-webgui") + + self.step("configuring ipa-webgui to start on boot") + service.chkconfig_on("ipa-webgui") + + self.done_creation() + + From prowley at redhat.com Mon Nov 5 18:46:51 2007 From: prowley at redhat.com (Pete Rowley) Date: Mon, 05 Nov 2007 10:46:51 -0800 Subject: [Freeipa-devel] [PATCH] configure referential integrity plugin In-Reply-To: <1194190278.21823.72.camel@localhost.localdomain> References: <472BAB0A.5000802@redhat.com> <1194190278.21823.72.camel@localhost.localdomain> Message-ID: <472F651B.1090903@redhat.com> Simo Sorce wrote: > I see no patch attached .. > > attached > Simo. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > -- Pete -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt 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 rcritten at redhat.com Mon Nov 5 18:59:49 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 05 Nov 2007 13:59:49 -0500 Subject: [Freeipa-devel] [PATCH] Make it possible to force the running of autogen In-Reply-To: <48b7a619dec60bf2b72a.1194280153@mahler.iad.redhat.com> References: <48b7a619dec60bf2b72a.1194280153@mahler.iad.redhat.com> Message-ID: <472F6825.2030006@redhat.com> Karl MacMillan wrote: > # HG changeset patch > # User "Karl MacMillan " > # Date 1194280068 18000 > # Node ID 48b7a619dec60bf2b72a34d7fdc2ab7adad7c01d > # Parent ceff443d46a3b3f64e7cd9ca4ae72758cd581ccd > Make it possible to force the running of autogen. > > With the change to run autogen on make all if there > was no makefile present, it became impossible to > force the running of autogen when that is needed. Fix > that by adding a bootstrap-autogen target that checks > the existing of Makefiles and reverting the autogen > target to always run autogen. 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 Mon Nov 5 19:00:02 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 05 Nov 2007 14:00:02 -0500 Subject: [Freeipa-devel] [PATCH] Prevent gzip from requesting confirmation In-Reply-To: <5a4b477d68ff5f26ea2d.1194280803@mahler.iad.redhat.com> References: <5a4b477d68ff5f26ea2d.1194280803@mahler.iad.redhat.com> Message-ID: <472F6832.605@redhat.com> Karl MacMillan wrote: > # HG changeset patch > # User "Karl MacMillan " > # Date 1194280799 18000 > # Node ID 5a4b477d68ff5f26ea2d445b83e5bf67f329df35 > # Parent 48b7a619dec60bf2b72a34d7fdc2ab7adad7c01d > Prevent gzip from requesting confirmation. > > The current manpage installation gzips the files in > place and requests confirmation before overwriting > existing files. Add -f to prevent prompting. We > should consider not gzipping the files in place. > 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 kmacmill at redhat.com Mon Nov 5 19:03:46 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Mon, 05 Nov 2007 14:03:46 -0500 Subject: [Fwd: [Freeipa-devel] [PATCH] implement self-service] Message-ID: <1194289426.505.22.camel@mahler.iad.redhat.com> -------- Forwarded Message -------- > From: Rob Crittenden > To: freeipa-devel > Subject: [Freeipa-devel] [PATCH] implement self-service > Date: Fri, 02 Nov 2007 17:42:14 -0400 > > Define Self-Service as editting your own record. > > This has the side-effect of removing the realm from 'Logged in as' in > the GUI. This can be changed by using user_name instead of display_name > in master.kid. Might be less confusing this way anyhow. > Pushed. From rcritten at redhat.com Mon Nov 5 19:04:50 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 05 Nov 2007 14:04:50 -0500 Subject: [Freeipa-devel] [PATCH] Introduce service base class and clean up ipa-server-install In-Reply-To: References: Message-ID: <472F6952.6020105@redhat.com> Karl MacMillan wrote: > # HG changeset patch > # User "Karl MacMillan " > # Date 1194284670 18000 > # Node ID db76e0233ab55b47ae226b2062a54c5a74441fe6 > # Parent 5a4b477d68ff5f26ea2d445b83e5bf67f329df35 > Introduce service base class and clean up ipa-server-install > > 1) Add a base class for all of the instance objects. > 2) Normalize usage of logging. > 3) General cleanups of ipa-server-install. > 4) Make better use of httpinstance. > 5) Add webguiinstance. > 6) Improve progress reporting during installation. > > Works Here (TM), but it would be nice to get someone else > to test since this moves code around a bit. I like the concept but you still mix a regular log (self.step) with a failure (logging.criticial). Should there be a wrapper like self.critical or self.failed around that? Fine as is 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 kmacmill at redhat.com Mon Nov 5 19:06:33 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Mon, 05 Nov 2007 14:06:33 -0500 Subject: [Freeipa-devel] [PATCH] configure referential integrity plugin In-Reply-To: <472F651B.1090903@redhat.com> References: <472BAB0A.5000802@redhat.com> <1194190278.21823.72.camel@localhost.localdomain> <472F651B.1090903@redhat.com> Message-ID: <1194289593.505.24.camel@mahler.iad.redhat.com> On Mon, 2007-11-05 at 10:46 -0800, Pete Rowley wrote: > Simo Sorce wrote: > > I see no patch attached .. > > > > > attached Pushed - there were minor merge errors, so please remember to do a pull before submission. Thanks - Karl From kmacmill at redhat.com Mon Nov 5 19:12:23 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Mon, 05 Nov 2007 14:12:23 -0500 Subject: [Freeipa-devel] [PATCH] Initial Radius Work In-Reply-To: <472CB702.4090405@redhat.com> References: <472CB702.4090405@redhat.com> Message-ID: <1194289943.505.29.camel@mahler.iad.redhat.com> On Sat, 2007-11-03 at 13:59 -0400, John Dennis wrote: > Attached are 3 mercurial changesets that comprise the initial work to > integrate freeradius with IPA, please review. > > Question: It would be easier to review the patch if the diffs were > cumulative rather than sequential (the last two changesets were minor > issues discovered during a test install). Is there a way to get mecurial > to roll up all the changes in a revision range into one diff? I couldn't > figure out how to do it. > You can either just use hg diff specifying multiple revisions or - what I recommend - use mercurial patch queues. http://www.selenic.com/mercurial/wiki/index.cgi/MqExtension > Note: This comprises only the IPA source changes. There is also a > significant change to the freeradius package in order to work with IPA. > Sometime soon I'll build and post a new freeradius rpm. I wanted to get > these initial changes out first for review ASAP. I went ahead and pulled in these changes to help with the merging of some other patches. A few comments: 1) Simo / Pete - can you please review the schema added. 2) What's is get_rpm_nvr_by_name used for? So far we have no explicit rpm deps in the code - I would very much like to keep it that way. Karl From kmacmill at redhat.com Mon Nov 5 19:14:17 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Mon, 05 Nov 2007 14:14:17 -0500 Subject: [Freeipa-devel] [PATCH] Make it possible to force the running of autogen In-Reply-To: <48b7a619dec60bf2b72a.1194280153@mahler.iad.redhat.com> References: <48b7a619dec60bf2b72a.1194280153@mahler.iad.redhat.com> Message-ID: <1194290057.505.31.camel@mahler.iad.redhat.com> On Mon, 2007-11-05 at 11:29 -0400, Karl MacMillan wrote: > # HG changeset patch > # User "Karl MacMillan " > # Date 1194280068 18000 > # Node ID 48b7a619dec60bf2b72a34d7fdc2ab7adad7c01d > # Parent ceff443d46a3b3f64e7cd9ca4ae72758cd581ccd > Make it possible to force the running of autogen. > > With the change to run autogen on make all if there > was no makefile present, it became impossible to > force the running of autogen when that is needed. Fix > that by adding a bootstrap-autogen target that checks > the existing of Makefiles and reverting the autogen > target to always run autogen. > Pushed. From kmacmill at redhat.com Mon Nov 5 19:16:59 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Mon, 05 Nov 2007 14:16:59 -0500 Subject: [Freeipa-devel] [PATCH] Introduce service base class and clean up ipa-server-install In-Reply-To: <472F6952.6020105@redhat.com> References: <472F6952.6020105@redhat.com> Message-ID: <1194290219.505.34.camel@mahler.iad.redhat.com> On Mon, 2007-11-05 at 14:04 -0500, Rob Crittenden wrote: > Karl MacMillan wrote: > > # HG changeset patch > > # User "Karl MacMillan " > > # Date 1194284670 18000 > > # Node ID db76e0233ab55b47ae226b2062a54c5a74441fe6 > > # Parent 5a4b477d68ff5f26ea2d445b83e5bf67f329df35 > > Introduce service base class and clean up ipa-server-install > > > > 1) Add a base class for all of the instance objects. > > 2) Normalize usage of logging. > > 3) General cleanups of ipa-server-install. > > 4) Make better use of httpinstance. > > 5) Add webguiinstance. > > 6) Improve progress reporting during installation. > > > > Works Here (TM), but it would be nice to get someone else > > to test since this moves code around a bit. > > I like the concept but you still mix a regular log (self.step) Well - this does a few things beyond just logging. > with a > failure (logging.criticial). Should there be a wrapper like > self.critical or self.failed around that? > I added a wrapper at first, but it really just renamed logging.critical. I couldn't think of where the abstraction would help, so I dropped it. I can change that if you feel strongly though. Karl From jdennis at redhat.com Mon Nov 5 19:36:46 2007 From: jdennis at redhat.com (John Dennis) Date: Mon, 05 Nov 2007 14:36:46 -0500 Subject: [Freeipa-devel] [PATCH] Initial Radius Work In-Reply-To: <1194289943.505.29.camel@mahler.iad.redhat.com> References: <472CB702.4090405@redhat.com> <1194289943.505.29.camel@mahler.iad.redhat.com> Message-ID: <472F70CE.2@redhat.com> Karl MacMillan wrote: > 2) What's is get_rpm_nvr_by_name used for? So far we have no explicit > rpm deps in the code - I would very much like to keep it that way. When configuring a service it's used to determine the service version. That way if there are any config file differences which are dependent on the version the resulting config file generation can properly take account of the version differences. To the best of my knowledge we're only requiring (via the spec file), certain packages be installed, or perhaps a minimum revision of a specific package. The ipa-server-install should be able to validate what its configuring and attempt to adapt to it or throw an error saying it encountered an unsupported version of a required service. We aren't planning on supporting ipa-server installs on non-rpm based systems, right? But even if we do the version query can use the mechanism of the host or return None (e.g. I don't know the version). -- John Dennis From kmacmill at redhat.com Mon Nov 5 19:39:11 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Mon, 05 Nov 2007 14:39:11 -0500 Subject: [Freeipa-devel] [PATCH] Initial Radius Work In-Reply-To: <472F70CE.2@redhat.com> References: <472CB702.4090405@redhat.com> <1194289943.505.29.camel@mahler.iad.redhat.com> <472F70CE.2@redhat.com> Message-ID: <1194291551.505.41.camel@mahler.iad.redhat.com> On Mon, 2007-11-05 at 14:36 -0500, John Dennis wrote: > Karl MacMillan wrote: > > 2) What's is get_rpm_nvr_by_name used for? So far we have no explicit > > rpm deps in the code - I would very much like to keep it that way. > > When configuring a service it's used to determine the service version. > That way if there are any config file differences which are dependent on > the version the resulting config file generation can properly take > account of the version differences. > > To the best of my knowledge we're only requiring (via the spec file), > certain packages be installed, or perhaps a minimum revision of a > specific package. The ipa-server-install should be able to validate what > its configuring and attempt to adapt to it or throw an error saying it > encountered an unsupported version of a required service. > Let's deal with that when we come to it - but I don't think parsing rpm versions is the correct approach. I'd rather look at the actual config files are grab the version from the application itself. > We aren't planning on supporting ipa-server installs on non-rpm based > systems, right? Yes - I hope that freeipa will be packaged for other distros. > But even if we do the version query can use the > mechanism of the host or return None (e.g. I don't know the version). Like I said - I'd rather just worry about this when the problem arises. Can you please send a patch to remove that code for now? Karl From kmacmill at redhat.com Mon Nov 5 19:43:34 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Mon, 05 Nov 2007 14:43:34 -0500 Subject: [Freeipa-devel] [PATCH] Introduce service base class and clean up ipa-server-install In-Reply-To: References: Message-ID: <1194291814.505.44.camel@mahler.iad.redhat.com> On Mon, 2007-11-05 at 12:44 -0400, Karl MacMillan wrote: > # HG changeset patch > # User "Karl MacMillan " > # Date 1194284670 18000 > # Node ID db76e0233ab55b47ae226b2062a54c5a74441fe6 > # Parent 5a4b477d68ff5f26ea2d445b83e5bf67f329df35 > Introduce service base class and clean up ipa-server-install > > 1) Add a base class for all of the instance objects. > 2) Normalize usage of logging. > 3) General cleanups of ipa-server-install. > 4) Make better use of httpinstance. > 5) Add webguiinstance. > 6) Improve progress reporting during installation. > > Works Here (TM), but it would be nice to get someone else > to test since this moves code around a bit. > After merging and updating for the freeradius patch I actually pushed the attached patch. Karl -------------- next part -------------- Introduce service base class and clean up ipa-server-install 1) Add a base class for all of the instance objects. 2) Normalize usage of logging. 3) General cleanups of ipa-server-install. 4) Make better use of httpinstance. 5) Add webguiinstance. 6) Improve progress reporting during installation. Works Here (TM), but it would be nice to get someone else to test since this moves code around a bit. diff -r b7816eac8557 ipa-server/ipa-install/ipa-server-install --- a/ipa-server/ipa-install/ipa-server-install Mon Nov 05 11:39:59 2007 -0500 +++ b/ipa-server/ipa-install/ipa-server-install Mon Nov 05 14:41:55 2007 -0500 @@ -48,6 +48,9 @@ import ipaserver.httpinstance import ipaserver.httpinstance import ipaserver.ntpinstance import ipaserver.radiusinstance +import ipaserver.webguiinstance + +from ipaserver import service from ipa.ipautil import run @@ -525,7 +528,11 @@ def main(): # Create a HTTP instance http = ipaserver.httpinstance.HTTPInstance() - http.create_instance() + http.create_instance(realm_name, host_name) + + # Create a Web Gui instance + webgui = ipaserver.webguiinstance.WebGuiInstance() + webgui.create_instance() # Create a radius instance radius = ipaserver.radiusinstance.RadiusInstance() @@ -548,68 +555,15 @@ def main(): bind.create_sample_bind_zone() # Restart ds and krb after configurations have been changed + service.print_msg("restarting the directory server") ds.restart() + + service.print_msg("restarting the KDC") krb.restart() # Configure ntpd ntp = ipaserver.ntpinstance.NTPInstance() ntp.create_instance() - - try: - selinux=0 - try: - if (os.path.exists('/usr/sbin/selinuxenabled')): - run(["/usr/sbin/selinuxenabled"]) - selinux=1 - except subprocess.CalledProcessError, e: - # selinuxenabled returns 1 if not enabled - pass - - if selinux: - # Allow apache to connect to the turbogears web gui - # This can still fail even if selinux is enabled - try: - run(["/usr/sbin/setsebool", "-P", "httpd_can_network_connect", "true"]) - except: - print "WARNING: could not set selinux boolean httpd_can_network_connect to true." - print "The web interface may not function correctly until this boolean is" - print "successfully change with the command:" - print " /usr/sbin/setsebool -P httpd_can_network_connect true" - print "Try updating the policycoreutils and selinux-policy packages." - pass - - # Start the web gui - run(["/sbin/service", "ipa-webgui", "start"]) - - # Set the web gui to start on boot - run(["/sbin/chkconfig", "ipa-webgui", "on"]) - - # Restart apache - run(["/sbin/service", "httpd", "restart"]) - - # Set apache to start on boot - run(["/sbin/chkconfig", "httpd", "on"]) - - # Set fedora-ds to start on boot - run(["/sbin/chkconfig", "dirsrv", "on"]) - - # Set the KDC to start on boot - run(["/sbin/chkconfig", "krb5kdc", "on"]) - - # Set the Kpasswd to start on boot - run(["/sbin/chkconfig", "ipa-kpasswd", "on"]) - - # Start Kpasswd - run(["/sbin/service", "ipa-kpasswd", "start"]) - - # Set the ntpd to start on boot - run(["/sbin/chkconfig", "ntpd", "on"]) - - # Restart ntpd - run(["/sbin/service", "ntpd", "restart"]) - except subprocess.CalledProcessError, e: - print "Installation failed:", e - return 1 # Set the admin user kerberos password ds.change_admin_password(admin_password) diff -r b7816eac8557 ipa-server/ipa-install/share/Makefile.am --- a/ipa-server/ipa-install/share/Makefile.am Mon Nov 05 11:39:59 2007 -0500 +++ b/ipa-server/ipa-install/share/Makefile.am Mon Nov 05 14:41:55 2007 -0500 @@ -19,6 +19,7 @@ app_DATA = \ krbrealm.con.template \ ntp.conf.server.template \ radius.radiusd.conf.template \ + referint-conf.ldif \ $(NULL) EXTRA_DIST = \ diff -r b7816eac8557 ipa-server/ipaserver/Makefile.am --- a/ipa-server/ipaserver/Makefile.am Mon Nov 05 11:39:59 2007 -0500 +++ b/ipa-server/ipaserver/Makefile.am Mon Nov 05 14:41:55 2007 -0500 @@ -10,6 +10,8 @@ app_PYTHON = \ httpinstance.py \ ntpinstance.py \ radiusinstance.py \ + webguiinstance.py \ + service.py \ $(NULL) EXTRA_DIST = \ diff -r b7816eac8557 ipa-server/ipaserver/dsinstance.py --- a/ipa-server/ipaserver/dsinstance.py Mon Nov 05 11:39:59 2007 -0500 +++ b/ipa-server/ipaserver/dsinstance.py Mon Nov 05 14:41:55 2007 -0500 @@ -24,7 +24,9 @@ import shutil import shutil import logging import pwd + from ipa.ipautil import * +import service SERVER_ROOT_64 = "/usr/lib64/dirsrv" SERVER_ROOT_32 = "/usr/lib/dirsrv" @@ -57,8 +59,9 @@ RootDNPwd= $PASSWORD RootDNPwd= $PASSWORD """ -class DsInstance: +class DsInstance(service.Service): def __init__(self): + service.Service.__init__(self, "dirsrv") self.serverid = None self.realm_name = None self.suffix = None @@ -75,6 +78,7 @@ class DsInstance: self.dm_password = dm_password self.__setup_sub_dict() + self.start_creation(11, "Configuring directory server:") self.__create_ds_user() self.__create_instance() self.__add_default_schemas() @@ -84,11 +88,17 @@ class DsInstance: self.__enable_ssl() self.__certmap_conf() try: + self.step("restarting directory server") self.restart() except: # TODO: roll back here? - print "Failed to restart the ds instance" + logging.critical("Failed to restart the ds instance") self.__add_default_layout() + + self.step("configuring directoy to start on boot") + self.chkconfig_on() + + self.done_creation() def config_dirname(self): if not self.serverid: @@ -97,15 +107,6 @@ class DsInstance: def schema_dirname(self): return self.config_dirname() + "/schema/" - - def stop(self): - run(["/sbin/service", "dirsrv", "stop"]) - - def start(self): - run(["/sbin/service", "dirsrv", "start"]) - - def restart(self): - run(["/sbin/service", "dirsrv", "restart"]) def __setup_sub_dict(self): server_root = find_server_root() @@ -115,6 +116,7 @@ class DsInstance: SERVER_ROOT=server_root) def __create_ds_user(self): + self.step("creating directory server user") try: pwd.getpwnam(self.ds_user) logging.debug("ds user %s exists" % self.ds_user) @@ -125,11 +127,10 @@ class DsInstance: run(args) logging.debug("done adding user") except subprocess.CalledProcessError, e: - print "Failed to add user", e - logging.debug("failed to add user %s" % e) + logging.critical("failed to add user %s" % e) def __create_instance(self): - logging.debug("creating ds instance . . . ") + self.step("creating directory server instance") inf_txt = template_str(INF_TEMPLATE, self.sub_dict) logging.debug(inf_txt) inf_fd = write_tmp_file(inf_txt) @@ -144,17 +145,17 @@ class DsInstance: run(args) logging.debug("completed creating ds instance") except subprocess.CalledProcessError, e: + logging.critical("failed to restart ds instance %s" % e) + logging.debug("restarting ds instance") + try: + self.restart() + logging.debug("done restarting ds instance") + except subprocess.CalledProcessError, e: print "failed to restart ds instance", e logging.debug("failed to restart ds instance %s" % e) - logging.debug("restarting ds instance") - try: - self.restart() - logging.debug("done restarting ds instance") - except subprocess.CalledProcessError, e: - print "failed to restart ds instance", e - logging.debug("failed to restart ds instance %s" % e) def __add_default_schemas(self): + self.step("adding default schema") shutil.copyfile(SHARE_DIR + "60kerberos.ldif", self.schema_dirname() + "60kerberos.ldif") shutil.copyfile(SHARE_DIR + "60samba.ldif", @@ -163,15 +164,17 @@ class DsInstance: self.schema_dirname() + "60radius.ldif") def __add_memberof_module(self): + self.step("enabling memboerof plugin") memberof_txt = template_file(SHARE_DIR + "memberof-conf.ldif", self.sub_dict) memberof_fd = write_tmp_file(memberof_txt) try: ldap_mod(memberof_fd, "cn=Directory Manager", self.dm_password) except subprocess.CalledProcessError, e: - print "Failed to load memberof-conf.ldif", e + logging.critical("Failed to load memberof-conf.ldif: %s" % str(e)) memberof_fd.close() def __add_referint_module(self): + self.step("enabling referential integrity plugin") referint_txt = template_file(SHARE_DIR + "referint-conf.ldif", self.sub_dict) referint_fd = write_tmp_file(referint_txt) try: @@ -181,7 +184,7 @@ class DsInstance: referint_fd.close() def __enable_ssl(self): - logging.debug("configuring ssl for ds instance") + self.step("configuring ssl for ds instance") dirname = self.config_dirname() args = ["/usr/share/ipa/ipa-server-setupssl", self.dm_password, dirname, self.host_name] @@ -189,13 +192,13 @@ class DsInstance: run(args) logging.debug("done configuring ssl for ds instance") except subprocess.CalledProcessError, e: - print "Failed to enable ssl in ds instance", e - logging.debug("Failed to configure ssl in ds instance %s" % e) + logging.critical("Failed to configure ssl in ds instance %s" % e) def __add_default_layout(self): + self.step("adding default layout") txt = template_file(SHARE_DIR + "bootstrap-template.ldif", self.sub_dict) inf_fd = write_tmp_file(txt) - logging.debug("adding default ds layout") + logging.debug("adding default dfrom ipa.ipautil import *s layout") args = ["/usr/bin/ldapmodify", "-xv", "-D", "cn=Directory Manager", "-w", self.dm_password, "-f", inf_fd.name] try: @@ -203,9 +206,10 @@ class DsInstance: logging.debug("done adding default ds layout") except subprocess.CalledProcessError, e: print "Failed to add default ds layout", e - logging.debug("Failed to add default ds layout %s" % e) + logging.critical("Failed to add default ds layout %s" % e) def __create_indeces(self): + self.step("creating indeces") txt = template_file(SHARE_DIR + "indeces.ldif", self.sub_dict) inf_fd = write_tmp_file(txt) logging.debug("adding/updating indeces") @@ -215,17 +219,15 @@ class DsInstance: run(args) logging.debug("done adding/updating indeces") except subprocess.CalledProcessError, e: - print "Failed to add default ds layout", e - logging.debug("Failed to add/update indeces %s" % e) + logging.critical("Failed to add/update indeces %s" % str(e)) def __certmap_conf(self): - logging.debug("configuring certmap.conf for ds instance") + self.step("configuring certmap.conf") dirname = self.config_dirname() certmap_conf = template_file(SHARE_DIR+"certmap.conf.template", self.sub_dict) certmap_fd = open(dirname+"certmap.conf", "w+") certmap_fd.write(certmap_conf) certmap_fd.close() - logging.debug("done configuring certmap.conf for ds instance") def change_admin_password(self, password): logging.debug("Changing admin password") diff -r b7816eac8557 ipa-server/ipaserver/httpinstance.py --- a/ipa-server/ipaserver/httpinstance.py Mon Nov 05 11:39:59 2007 -0500 +++ b/ipa-server/ipaserver/httpinstance.py Mon Nov 05 14:41:55 2007 -0500 @@ -20,16 +20,25 @@ import subprocess import subprocess import string import tempfile -import shutil import logging import pwd -from ipa.ipautil import * import fileinput import sys +import time + +import service +from ipa.ipautil import * HTTPD_DIR = "/etc/httpd" SSL_CONF = HTTPD_DIR + "/conf.d/ssl.conf" NSS_CONF = HTTPD_DIR + "/conf.d/nss.conf" + +selinux_warning = """WARNING: could not set selinux boolean httpd_can_network_connect to true. +The web interface may not function correctly until this boolean is +successfully change with the command: + /usr/sbin/setsebool -P httpd_can_network_connect true +Try updating the policycoreutils and selinux-policy packages. +""" def update_file(filename, orig, subst): if os.path.exists(filename): @@ -42,35 +51,90 @@ def update_file(filename, orig, subst): sys.stdout.write(p.sub(subst, line)) fileinput.close() -class HTTPInstance: +class HTTPInstance(service.Service): def __init__(self): - pass + service.Service.__init__(self, "httpd") - def create_instance(self): + def create_instance(self, realm, fqdn): + self.sub_dict = { "REALM" : realm } + self.fqdn = fqdn + self.realm = realm + + self.start_creation(6, "Configuring the web interface") + self.__disable_mod_ssl() self.__set_mod_nss_port() + self.__configure_http() + self.__create_http_keytab() + + self.step("restarting httpd") + self.restart() + + self.step("configuring httpd to start on boot") + self.chkconfig_on() + + self.done_creation() + + def __selinux_config(self): + self.step("configuring SELinux for httpd") + selinux=0 try: - self.restart() - except: - # TODO: roll back here? - print "Failed to restart httpd" + if (os.path.exists('/usr/sbin/selinuxenabled')): + run(["/usr/sbin/selinuxenabled"]) + selinux=1 + except subprocess.CalledProcessError: + # selinuxenabled returns 1 if not enabled + pass - def stop(self): - run(["/sbin/service", "httpd", "stop"]) + if selinux: + # Allow apache to connect to the turbogears web gui + # This can still fail even if selinux is enabled + try: + run(["/usr/sbin/setsebool", "-P", "httpd_can_network_connect", "true"]) + except: + self.print_msg(selinux_warning) + + def __create_http_keytab(self): + self.step("creating a keytab for httpd") + try: + if file_exists("/etc/httpd/conf/ipa.keytab"): + os.remove("/etc/httpd/conf/ipa.keytab") + except os.error: + print "Failed to remove /etc/httpd/conf/ipa.keytab." + (kwrite, kread, kerr) = os.popen3("/usr/kerberos/sbin/kadmin.local") + kwrite.write("addprinc -randkey HTTP/"+self.fqdn+"@"+self.realm+"\n") + kwrite.flush() + kwrite.write("ktadd -k /etc/httpd/conf/ipa.keytab HTTP/"+self.fqdn+"@"+self.realm+"\n") + kwrite.flush() + kwrite.close() + kread.close() + kerr.close() - def start(self): - run(["/sbin/service", "httpd", "start"]) + # give kadmin time to actually write the file before we go on + retry = 0 + while not file_exists("/etc/httpd/conf/ipa.keytab"): + time.sleep(1) + retry += 1 + if retry > 15: + print "Error timed out waiting for kadmin to finish operations\n" + sys.exit(1) - def restart(self): - run(["/sbin/service", "httpd", "restart"]) + pent = pwd.getpwnam("apache") + os.chown("/etc/httpd/conf/ipa.keytab", pent.pw_uid, pent.pw_gid) + + def __configure_http(self): + self.step("configuring httpd") + http_txt = template_file(SHARE_DIR + "ipa.conf", self.sub_dict) + http_fd = open("/etc/httpd/conf.d/ipa.conf", "w") + http_fd.write(http_txt) + http_fd.close() + def __disable_mod_ssl(self): - logging.debug("disabling mod_ssl in httpd") + self.step("disabling mod_ssl in httpd") if os.path.exists(SSL_CONF): os.rename(SSL_CONF, "%s.moved_by_ipa" % SSL_CONF) - logging.debug("done disabling mod_ssl") def __set_mod_nss_port(self): - logging.debug("Setting mod_nss port to 443") + self.step("Setting mod_nss port to 443") update_file(NSS_CONF, '8443', '443') - logging.debug("done setting mod_nss port") diff -r b7816eac8557 ipa-server/ipaserver/krbinstance.py --- a/ipa-server/ipaserver/krbinstance.py Mon Nov 05 11:39:59 2007 -0500 +++ b/ipa-server/ipaserver/krbinstance.py Mon Nov 05 14:41:55 2007 -0500 @@ -32,6 +32,8 @@ import pwd import pwd import socket import time + +import service from ipa.ipautil import * def host_to_domain(fqdn): @@ -63,8 +65,9 @@ def update_key_val_in_file(filename, key f.write("%s=%s\n" % (key, val)) f.close() -class KrbInstance: +class KrbInstance(service.Service): def __init__(self): + service.Service.__init__(self, "krb5kdc") self.ds_user = None self.fqdn = None self.realm = None @@ -95,39 +98,41 @@ class KrbInstance: # It could have been not running pass + self.start_creation(10, "Configuring Kerberos KDC") + self.__configure_kdc_account_password() self.__setup_sub_dict() self.__configure_ldap() - self.__configure_http() - self.__create_instance() self.__create_ds_keytab() - self.__create_http_keytab() - self.__export_kadmin_changepw_keytab() self.__add_pwd_extop_module() try: + self.step("starting the KDC") self.start() except: - print "krb5kdc service failed to start" - - def stop(self): - run(["/sbin/service", "krb5kdc", "stop"]) - - def start(self): - run(["/sbin/service", "krb5kdc", "start"]) - - def restart(self): - run(["/sbin/service", "krb5kdc", "restart"]) + logging.critical("krb5kdc service failed to start") + + self.step("configuring KDC to start on boot") + self.chkconfig_on() + + self.step("configuring ipa-kpasswd to start on boot") + service.chkconfig_on("ipa-kpasswd") + + self.step("starting ipa-kpasswd") + service.start("ipa-kpasswd") + + self.done_creation() def __configure_kdc_account_password(self): + self.step("setting KDC account password") hexpwd = '' for x in self.kdc_password: hexpwd += (hex(ord(x))[2:]) @@ -145,14 +150,14 @@ class KrbInstance: REALM=self.realm) def __configure_ldap(self): - + self.step("adding kerberos configuration to the directory") #TODO: test that the ldif is ok with any random charcter we may use in the password kerberos_txt = template_file(SHARE_DIR + "kerberos.ldif", self.sub_dict) kerberos_fd = write_tmp_file(kerberos_txt) try: ldap_mod(kerberos_fd, "cn=Directory Manager", self.admin_password) except subprocess.CalledProcessError, e: - print "Failed to load kerberos.ldif", e + logging.critical("Failed to load kerberos.ldif: %s" % str(e)) kerberos_fd.close() #Change the default ACL to avoid anonimous access to kerberos keys and othe hashes @@ -161,10 +166,11 @@ class KrbInstance: try: ldap_mod(aci_fd, "cn=Directory Manager", self.admin_password) except subprocess.CalledProcessError, e: - print "Failed to load default-aci.ldif", e + logging.critical("Failed to load default-aci.ldif: %s" % str(e)) aci_fd.close() def __create_instance(self): + self.step("configuring KDC") kdc_conf = template_file(SHARE_DIR+"kdc.conf.template", self.sub_dict) kdc_fd = open("/var/kerberos/krb5kdc/kdc.conf", "w+") kdc_fd.write(kdc_conf) @@ -200,12 +206,13 @@ class KrbInstance: #add the password extop module def __add_pwd_extop_module(self): + self.step("adding the password extenstion to the directory") extop_txt = template_file(SHARE_DIR + "pwd-extop-conf.ldif", self.sub_dict) extop_fd = write_tmp_file(extop_txt) try: ldap_mod(extop_fd, "cn=Directory Manager", self.admin_password) except subprocess.CalledProcessError, e: - print "Failed to load pwd-extop-conf.ldif", e + logging.critical("Failed to load pwd-extop-conf.ldif: %s" % str(e)) extop_fd.close() #add an ACL to let the DS user read the master key @@ -213,14 +220,15 @@ class KrbInstance: try: run(args) except subprocess.CalledProcessError, e: - print "Failed to set the ACL on the master key", e + logging.critical("Failed to set the ACL on the master key: %s" % str(e)) def __create_ds_keytab(self): + self.step("creating a keytab for the directory") try: if file_exists("/etc/dirsrv/ds.keytab"): os.remove("/etc/dirsrv/ds.keytab") except os.error: - print "Failed to remove /etc/dirsrv/ds.keytab." + logging.critical("Failed to remove /etc/dirsrv/ds.keytab.") (kwrite, kread, kerr) = os.popen3("/usr/kerberos/sbin/kadmin.local") kwrite.write("addprinc -randkey ldap/"+self.fqdn+"@"+self.realm+"\n") kwrite.flush() @@ -236,7 +244,7 @@ class KrbInstance: time.sleep(1) retry += 1 if retry > 15: - print "Error timed out waiting for kadmin to finish operations\n" + logging.critical("Error timed out waiting for kadmin to finish operations") sys.exit(1) update_key_val_in_file("/etc/sysconfig/dirsrv", "export KRB5_KTNAME", "/etc/dirsrv/ds.keytab") @@ -244,6 +252,7 @@ class KrbInstance: os.chown("/etc/dirsrv/ds.keytab", pent.pw_uid, pent.pw_gid) def __export_kadmin_changepw_keytab(self): + self.step("exporting the kadmin keytab") (kwrite, kread, kerr) = os.popen3("/usr/kerberos/sbin/kadmin.local") kwrite.write("modprinc +requires_preauth kadmin/changepw\n") kwrite.flush() @@ -264,42 +273,11 @@ class KrbInstance: time.sleep(1) retry += 1 if retry > 15: - print "Error timed out waiting for kadmin to finish operations\n" + logging.critical("Error timed out waiting for kadmin to finish operations") sys.exit(1) update_key_val_in_file("/etc/sysconfig/ipa-kpasswd", "export KRB5_KTNAME", "/var/kerberos/krb5kdc/kpasswd.keytab") pent = pwd.getpwnam(self.ds_user) os.chown("/var/kerberos/krb5kdc/kpasswd.keytab", pent.pw_uid, pent.pw_gid) - def __create_http_keytab(self): - try: - if file_exists("/etc/httpd/conf/ipa.keytab"): - os.remove("/etc/httpd/conf/ipa.keytab") - except os.error: - print "Failed to remove /etc/httpd/conf/ipa.keytab." - (kwrite, kread, kerr) = os.popen3("/usr/kerberos/sbin/kadmin.local") - kwrite.write("addprinc -randkey HTTP/"+self.fqdn+"@"+self.realm+"\n") - kwrite.flush() - kwrite.write("ktadd -k /etc/httpd/conf/ipa.keytab HTTP/"+self.fqdn+"@"+self.realm+"\n") - kwrite.flush() - kwrite.close() - kread.close() - kerr.close() - - # give kadmin time to actually write the file before we go on - retry = 0 - while not file_exists("/etc/httpd/conf/ipa.keytab"): - time.sleep(1) - retry += 1 - if retry > 15: - print "Error timed out waiting for kadmin to finish operations\n" - sys.exit(1) - - pent = pwd.getpwnam("apache") - os.chown("/etc/httpd/conf/ipa.keytab", pent.pw_uid, pent.pw_gid) - - def __configure_http(self): - http_txt = template_file(SHARE_DIR + "ipa.conf", self.sub_dict) - http_fd = open("/etc/httpd/conf.d/ipa.conf", "w") - http_fd.write(http_txt) - http_fd.close() + diff -r b7816eac8557 ipa-server/ipaserver/ntpinstance.py --- a/ipa-server/ipaserver/ntpinstance.py Mon Nov 05 11:39:59 2007 -0500 +++ b/ipa-server/ipaserver/ntpinstance.py Mon Nov 05 14:41:55 2007 -0500 @@ -20,8 +20,16 @@ from ipa.ipautil import * from ipa.ipautil import * import shutil -class NTPInstance: +import service + +class NTPInstance(service.Service): + def __init__(self): + service.Service.__init__(self, "ntpd") + def create_instance(self): + self.start_creation(3, "Configuring ntpd") + + self.step("writing configuration") # The template sets the config to point towards ntp.pool.org, but # they request that software not point towards the default pool. # We use the OS variable to point it towards either the rhel @@ -48,3 +56,9 @@ class NTPInstance: # we might consider setting the date manually using ntpd -qg in case # the current time is very far off. + + self.step("starting ntpd") + self.start() + + self.step("configuring ntpd to start on boot") + self.chkconfig_on() diff -r b7816eac8557 ipa-server/ipaserver/radiusinstance.py --- a/ipa-server/ipaserver/radiusinstance.py Mon Nov 05 11:39:59 2007 -0500 +++ b/ipa-server/ipaserver/radiusinstance.py Mon Nov 05 14:41:55 2007 -0500 @@ -27,6 +27,8 @@ import time import time from ipa.ipautil import * +import service + import os import re @@ -47,8 +49,9 @@ from ipaserver.funcs import DefaultUserC #------------------------------------------------------------------------------- -class RadiusInstance: +class RadiusInstance(service.Service): def __init__(self): + service.Service.__init__(self, "radiusd") self.fqdn = None self.realm = None self.principal = None @@ -66,6 +69,8 @@ class RadiusInstance: else: self.rpm_name = self.rpm_version = self.rpm_release = None + self.start_creation(4, "Configuring radiusd") + try: self.stop() except: @@ -76,22 +81,17 @@ class RadiusInstance: self.__radiusd_conf() try: + self.step("starting radiusd") self.start() except: logging.error("radiusd service failed to start") + self.step("configuring radiusd to start on boot") + self.chkconfig_on() - def stop(self): - run(['/sbin/service', 'radiusd', 'stop']) - - def start(self): - run(['/sbin/service', 'radiusd', 'start']) - - def restart(self): - run(['/sbin/service', 'radiusd', 'restart']) def __radiusd_conf(self): - logging.debug('configuring radiusd.conf for radius instance') + self.step('configuring radiusd.conf for radius instance') version = 'IPA_RADIUS_VERSION=%s RADIUS_PACKAGE_VERSION=%s' % (IPA_RADIUS_VERSION, self.rpm_nvr) sub_dict = {'CONFIG_FILE_VERSION_INFO' : version, @@ -110,6 +110,7 @@ class RadiusInstance: logging.error("could not create %s: %s", RADIUSD_CONF_FILEPATH, e) def __create_radius_keytab(self): + self.step("create radiusd keytab") try: if file_exists(IPA_KEYTAB_FILEPATH): os.remove(IPA_KEYTAB_FILEPATH) diff -r b7816eac8557 ipa-server/ipaserver/service.py --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/ipa-server/ipaserver/service.py Mon Nov 05 14:41:55 2007 -0500 @@ -0,0 +1,86 @@ +# Authors: Karl MacMillan +# +# Copyright (C) 2007 Red Hat +# see file 'COPYING' for use and warranty information +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; version 2 or later +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA +# + +from ipa.ipautil import * +import logging, sys + + +def stop(service_name): + run(["/sbin/service", service_name, "stop"]) + +def start(service_name): + run(["/sbin/service", service_name, "start"]) + +def restart(service_name): + run(["/sbin/service", service_name, "restart"]) + +def chkconfig_on(service_name): + run(["/sbin/chkconfig", service_name, "on"]) + +def chkconfig_off(service_name): + run(["/sbin/chkconfig", service_name, "off"]) + +def print_msg(message, output_fd=sys.stdout): + logging.debug(message) + output_fd.write(message) + output_fd.write("\n") + + +class Service: + def __init__(self, service_name): + self.service_name = service_name + self.num_steps = -1 + self.current_step = -1 + self.output_fd = sys.stdout + + def set_output(self, fd): + self.output_fd = fd + + def stop(self): + stop(self.service_name) + + def start(self): + start(self.service_name) + + def restart(self): + restart(self.service_name) + + def chkconfig_on(self): + chkconfig_on(self.service_name) + + def chkconfig_off(self): + chkconfig_off(self.service_name) + + def print_msg(self, message): + print_msg(message, self.output_fd) + + def start_creation(self, num_steps, message): + self.num_steps = num_steps + self.cur_step = 0 + self.print_msg(message) + + def step(self, message): + self.cur_step += 1 + self.print_msg(" [%d/%d]: %s" % (self.cur_step, self.num_steps, message)) + + def done_creation(self): + self.cur_step = -1 + self.num_steps = -1 + self.print_msg("done configuring %s." % self.service_name) + diff -r b7816eac8557 ipa-server/ipaserver/webguiinstance.py --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/ipa-server/ipaserver/webguiinstance.py Mon Nov 05 14:41:55 2007 -0500 @@ -0,0 +1,40 @@ +# Authors: Karl MacMillan +# +# Copyright (C) 2007 Red Hat +# see file 'COPYING' for use and warranty information +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; version 2 or later +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA +# + +import logging + +from ipa.ipautil import * +import service + +class WebGuiInstance(service.Service): + def __init__(self): + service.Service.__init__(self, "ipa-webgui") + + def create_instance(self): + self.start_creation(2, "Configuring ipa-webgui") + + self.step("starting ipa-webgui") + service.start("ipa-webgui") + + self.step("configuring ipa-webgui to start on boot") + service.chkconfig_on("ipa-webgui") + + self.done_creation() + + From prowley at redhat.com Mon Nov 5 20:20:38 2007 From: prowley at redhat.com (Pete Rowley) Date: Mon, 05 Nov 2007 12:20:38 -0800 Subject: [Freeipa-devel] [PATCH] Initial Radius Work In-Reply-To: <1194289943.505.29.camel@mahler.iad.redhat.com> References: <472CB702.4090405@redhat.com> <1194289943.505.29.camel@mahler.iad.redhat.com> Message-ID: <472F7B16.9000605@redhat.com> Karl MacMillan wrote: > On Sat, 2007-11-03 at 13:59 -0400, John Dennis wrote: > >> Attached are 3 mercurial changesets that comprise the initial work to >> integrate freeradius with IPA, please review. >> >> Question: It would be easier to review the patch if the diffs were >> cumulative rather than sequential (the last two changesets were minor >> issues discovered during a test install). Is there a way to get mecurial >> to roll up all the changes in a revision range into one diff? I couldn't >> figure out how to do it. >> >> > > You can either just use hg diff specifying multiple revisions or - what > I recommend - use mercurial patch queues. > > http://www.selenic.com/mercurial/wiki/index.cgi/MqExtension > > >> Note: This comprises only the IPA source changes. There is also a >> significant change to the freeradius package in order to work with IPA. >> Sometime soon I'll build and post a new freeradius rpm. I wanted to get >> these initial changes out first for review ASAP. >> > > I went ahead and pulled in these changes to help with the merging of > some other patches. A few comments: > > 1) Simo / Pete - can you please review the schema added. > Looks good. -- Pete -------------- 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 prowley at redhat.com Tue Nov 6 00:31:11 2007 From: prowley at redhat.com (Pete Rowley) Date: Mon, 05 Nov 2007 16:31:11 -0800 Subject: [Freeipa-devel] [PATCH] post install memberof task Message-ID: <472FB5CF.6060103@redhat.com> Set off the task to initialize memberof for existing users. -- Pete -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt 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 david.obrien at redhat.com Tue Nov 6 04:22:46 2007 From: david.obrien at redhat.com (David O'Brien) Date: Tue, 06 Nov 2007 14:22:46 +1000 Subject: [Freeipa-devel] Where do ipa-server install logs go? Message-ID: <472FEC16.5050303@redhat.com> I'm only assuming that they get created, of course... Is there a "standard" log directory for ipa? thanks -- /david -------------- next part -------------- A non-text attachment was scrubbed... Name: david.obrien.vcf Type: text/x-vcard Size: 310 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From david.obrien at redhat.com Tue Nov 6 06:35:53 2007 From: david.obrien at redhat.com (David O'Brien) Date: Tue, 06 Nov 2007 16:35:53 +1000 Subject: [Freeipa-devel] Minor issue on ipa web interface Message-ID: <47300B49.2050108@redhat.com> I've just installed freeipa-server from the 2007-11-05_10_07-build and noticed that the task bar is now on the right, but the text still reads "select a task from the left sidebar". cheers -- /david -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From david.obrien at redhat.com Tue Nov 6 07:30:31 2007 From: david.obrien at redhat.com (David O'Brien) Date: Tue, 06 Nov 2007 17:30:31 +1000 Subject: [Freeipa-devel] GSSAPI Authorization error while trying to add a group Message-ID: <47301817.4050905@redhat.com> Using freeipa-server from the 2007-11-05_10_07-build, I tried to add a group: Name: engineering Description: all engineering dept. members and got the following: Group add failed: GSSAPI Authorization error {'info': 'SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No such file or diectory)', 'desc':'Invalid credentials'} I'm logged in as admin. I'm trying to do this via the web interface. haven't tried the commandline tools yet. I also tried with no description and got the same result. I didn't try to add any members (haven't created any users yet). anyone else seen/tried this? -- /david -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From david.obrien at redhat.com Tue Nov 6 08:10:05 2007 From: david.obrien at redhat.com (David O'Brien) Date: Tue, 06 Nov 2007 18:10:05 +1000 Subject: [Freeipa-devel] issues with new ipa admin web interface Message-ID: <4730215D.7030108@redhat.com> The new interface doesn't give any indication of which fields are mandatory. I filled in what I thought looked necessary, but "email" and "see also" are also currently required. You don't discover this until after you have clicked "add person", and you get validation errors. Still trying to resolve the "GSSAPI Authorization error" too. I ran kinit admin and got a ticket before trying any of this, but there is still a fly in the ointment somewhere... cheers -- /david -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From david.obrien at redhat.com Tue Nov 6 08:11:23 2007 From: david.obrien at redhat.com (David O'Brien) Date: Tue, 06 Nov 2007 18:11:23 +1000 Subject: [Freeipa-devel] GSSAPI Authorization error while trying to add a group Message-ID: <473021AB.8080503@redhat.com> Using freeipa-server from the 2007-11-05_10_07-build, I tried to add a group: Name: engineering Description: all engineering dept. members and got the following: Group add failed: GSSAPI Authorization error {'info': 'SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No such file or diectory)', 'desc':'Invalid credentials'} I'm logged in as admin. I'm trying to do this via the web interface. haven't tried the commandline tools yet. I also tried with no description and got the same result. I didn't try to add any members (haven't created any users yet). anyone else seen/tried this? -- /david -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From kmacmill at redhat.com Tue Nov 6 12:45:55 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 06 Nov 2007 07:45:55 -0500 Subject: [Freeipa-devel] Where do ipa-server install logs go? In-Reply-To: <472FEC16.5050303@redhat.com> References: <472FEC16.5050303@redhat.com> Message-ID: <1194353155.4104.18.camel@localhost.localdomain> On Tue, 2007-11-06 at 14:22 +1000, David O'Brien wrote: > I'm only assuming that they get created, of course... Is there a > "standard" log directory for ipa? > /var/log/ipa_error.log. The httpd logs, krb5kdc, and dirsrv logs also have relevant troubleshooting information. However - these are not "install" logs, they are runtime logs. The install log is in the directory you ran the installer in a file called ipaserver-install.log. Karl From kmacmill at redhat.com Tue Nov 6 12:48:48 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 06 Nov 2007 07:48:48 -0500 Subject: [Freeipa-devel] Minor issue on ipa web interface In-Reply-To: <47300B49.2050108@redhat.com> References: <47300B49.2050108@redhat.com> Message-ID: <1194353328.4104.22.camel@localhost.localdomain> On Tue, 2007-11-06 at 16:35 +1000, David O'Brien wrote: > I've just installed freeipa-server from the 2007-11-05_10_07-build and > noticed that the task bar is now on the right, but the text still reads > "select a task from the left sidebar". > Added ticket #80 - feel free to file bugs at https://hosted.fedoraproject.org/projects/freeipa/. Karl From kmacmill at redhat.com Tue Nov 6 12:50:33 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 06 Nov 2007 07:50:33 -0500 Subject: [Freeipa-devel] issues with new ipa admin web interface In-Reply-To: <4730215D.7030108@redhat.com> References: <4730215D.7030108@redhat.com> Message-ID: <1194353433.4104.25.camel@localhost.localdomain> On Tue, 2007-11-06 at 18:10 +1000, David O'Brien wrote: > The new interface doesn't give any indication of which fields are > mandatory. I filled in what I thought looked necessary, but "email" and > "see also" are also currently required. You don't discover this until > after you have clicked "add person", and you get validation errors. > Known bug - should be fixed in the next milestone. Karl From kmacmill at redhat.com Tue Nov 6 12:52:20 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 06 Nov 2007 07:52:20 -0500 Subject: [Freeipa-devel] GSSAPI Authorization error while trying to add a group In-Reply-To: <473021AB.8080503@redhat.com> References: <473021AB.8080503@redhat.com> Message-ID: <1194353541.4104.29.camel@localhost.localdomain> On Tue, 2007-11-06 at 18:11 +1000, David O'Brien wrote: > Using freeipa-server from the 2007-11-05_10_07-build, I tried to add a > group: > Name: engineering > Description: all engineering dept. members > > and got the following: > > Group add failed: GSSAPI Authorization error > {'info': 'SASL(-1): generic failure: GSSAPI Error: Unspecified GSS > failure. Minor code may provide more information > (No such file or diectory)', 'desc':'Invalid credentials'} > > I'm logged in as admin. I'm trying to do this via the web interface. > haven't tried the commandline tools yet. > > I also tried with no description and got the same result. I didn't try > to add any members (haven't created any users yet). > > anyone else seen/tried this? > Do you verify that all your packages are updated as it says in http://freeipa.org/page/QuickInstall? Particularly PyKerberos and mod_auth_kerb. Are the client and server on the same host? What does hostname return? Can you search for users successfully? Os version / arch? Karl From david.obrien at redhat.com Tue Nov 6 14:04:35 2007 From: david.obrien at redhat.com (David O'Brien) Date: Wed, 07 Nov 2007 00:04:35 +1000 Subject: [Freeipa-devel] Where do ipa-server install logs go? In-Reply-To: <1194353155.4104.18.camel@localhost.localdomain> References: <472FEC16.5050303@redhat.com> <1194353155.4104.18.camel@localhost.localdomain> Message-ID: <47307473.3080807@redhat.com> Karl MacMillan wrote: > On Tue, 2007-11-06 at 14:22 +1000, David O'Brien wrote: >> I'm only assuming that they get created, of course... Is there a >> "standard" log directory for ipa? >> > > /var/log/ipa_error.log. The httpd logs, krb5kdc, and dirsrv logs also > have relevant troubleshooting information. > > However - these are not "install" logs, they are runtime logs. The > install log is in the directory you ran the installer in a file called > ipaserver-install.log. > > Karl > > thanks. I found the error log but not the other one. -- /david -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From rcritten at redhat.com Tue Nov 6 14:18:04 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 Nov 2007 09:18:04 -0500 Subject: [Freeipa-devel] [PATCH] post install memberof task In-Reply-To: <472FB5CF.6060103@redhat.com> References: <472FB5CF.6060103@redhat.com> Message-ID: <4730779C.1070409@redhat.com> Pete Rowley wrote: > Set off the task to initialize memberof for existing users. > > > 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 david.obrien at redhat.com Tue Nov 6 14:42:40 2007 From: david.obrien at redhat.com (David O'Brien) Date: Wed, 07 Nov 2007 00:42:40 +1000 Subject: [Freeipa-devel] GSSAPI Authorization error while trying to add a group In-Reply-To: <1194353541.4104.29.camel@localhost.localdomain> References: <473021AB.8080503@redhat.com> <1194353541.4104.29.camel@localhost.localdomain> Message-ID: <47307D60.3090801@redhat.com> Karl MacMillan wrote: > On Tue, 2007-11-06 at 18:11 +1000, David O'Brien wrote: >> Using freeipa-server from the 2007-11-05_10_07-build, I tried to add a >> group: >> Name: engineering >> Description: all engineering dept. members >> >> and got the following: >> >> Group add failed: GSSAPI Authorization error >> {'info': 'SASL(-1): generic failure: GSSAPI Error: Unspecified GSS >> failure. Minor code may provide more information >> (No such file or diectory)', 'desc':'Invalid credentials'} >> >> I'm logged in as admin. I'm trying to do this via the web interface. >> haven't tried the commandline tools yet. >> >> I also tried with no description and got the same result. I didn't try >> to add any members (haven't created any users yet). >> >> anyone else seen/tried this? >> > > Do you verify that all your packages are updated as it says in > http://freeipa.org/page/QuickInstall? Particularly PyKerberos and > mod_auth_kerb. > > Are the client and server on the same host? What does hostname return? > > Can you search for users successfully? > > Os version / arch? > > Karl > > ok, I should have read a bit further on the page and found info on GSS failures :( I can successfully add a user from the command line. haven't tried the web interface yet but suspect that will work. btw, why are most of the commands ipa- (e.g., ipa-adduser) except for mod? They are ipa-groupmod and ipa-usermod? The only thing I did different this time was apply the dirsrv patch. We didn't do that in the initial "hand-holding" session so I guessed it was "old". mod_auth_kerb was fine. Didn't see anything about PyKerberos... At the moment I'm running only the server. I have another vm handy that I'm going to put a client on. I prefer to test/document in some semblance of a "real" environment. mgregg helped me with initial hostname requirements so that part I've got under control. Currently on 32-bit F7. thanks -- /david -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jdennis at redhat.com Tue Nov 6 14:46:29 2007 From: jdennis at redhat.com (John Dennis) Date: Tue, 06 Nov 2007 09:46:29 -0500 Subject: [Freeipa-devel] setting up a local bind server for IPA Message-ID: <47307E45.7090003@redhat.com> I seem to be plagued with a number of problems running from the tip (mainline) after doing a new server install. I strongly suspect a number of these problems are related to not having a reverse DNS mapping for my test machine (it's currently dhcp configured). So I was going to set up a local bind server with a tiny zone which just had my test machine it it. I've heard a rumor many of you are running your own dns servers, so I presume this is recommended if not necessary, correct? O.K. so I'm not a bind administrator, although I could figure this out it's not the best use of my time. Do we have a HOWTO or set of bind configuration files for this purpose so I can minimize the amount of time spent on this diversion? In the mean time I'm going to see if I can roll my own configuration unless someone tells me this is not necessary or you've got a sample set up you can share. -- John Dennis From rcritten at redhat.com Tue Nov 6 15:23:54 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 Nov 2007 10:23:54 -0500 Subject: [Freeipa-devel] [PATCH] fix welcome text Message-ID: <4730870A.7070608@redhat.com> This patch is so trivial I went ahead and pushed it. It fixes the sidebar text on the welcome screen from "left" to "right". rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-365-sidebar.patch Type: text/x-patch Size: 793 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 Nov 6 15:36:03 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 Nov 2007 10:36:03 -0500 Subject: [Freeipa-devel] multi-valued fields Message-ID: <473089E3.8070406@redhat.com> The multi-valued field problem is turning out to be a hard nut to crack. I have a semi-working prototype now but I need to know which attributes we will allow to be multi-valued. Currently it supports just 'cn' on the user pages. I'll add support to group as well. Group membership is handled differently so isn't quite a multi-valued issue. I'd rather not enable multi-valued fields on every attribute just because LDAP supports them. I fear it will uglify the UI something fierce. I've attached a screenshot of what my current mock-up looks like. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: multivalue2.jpg Type: image/jpeg Size: 69448 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 rmeggins at redhat.com Tue Nov 6 15:40:58 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Tue, 06 Nov 2007 08:40:58 -0700 Subject: [Freeipa-devel] multi-valued fields In-Reply-To: <473089E3.8070406@redhat.com> References: <473089E3.8070406@redhat.com> Message-ID: <47308B0A.3070601@redhat.com> Rob Crittenden wrote: > The multi-valued field problem is turning out to be a hard nut to > crack. I have a semi-working prototype now but I need to know which > attributes we will allow to be multi-valued. > > Currently it supports just 'cn' on the user pages. I'll add support to > group as well. Group membership is handled differently so isn't quite > a multi-valued issue. > > I'd rather not enable multi-valued fields on every attribute just > because LDAP supports them. I fear it will uglify the UI something > fierce. > > I've attached a screenshot of what my current mock-up looks like. Another way to do it would be to have a text box, with a line for each value. For some attributes, that may be easier than add/remove value buttons. > > 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: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From david.obrien at redhat.com Tue Nov 6 15:43:27 2007 From: david.obrien at redhat.com (David O'Brien) Date: Wed, 07 Nov 2007 01:43:27 +1000 Subject: [Freeipa-devel] multi-valued fields In-Reply-To: <473089E3.8070406@redhat.com> References: <473089E3.8070406@redhat.com> Message-ID: <47308B9F.2000405@redhat.com> Don't know exactly the problem you're trying to solve, but the first thing that came to mind was, instead of multiple fields, just comma-separate the values in a single field. Rob Crittenden, Robby, robc Does that work? /david Rob Crittenden wrote: > The multi-valued field problem is turning out to be a hard nut to crack. > I have a semi-working prototype now but I need to know which attributes > we will allow to be multi-valued. > > Currently it supports just 'cn' on the user pages. I'll add support to > group as well. Group membership is handled differently so isn't quite a > multi-valued issue. > > I'd rather not enable multi-valued fields on every attribute just > because LDAP supports them. I fear it will uglify the UI something fierce. > > I've attached a screenshot of what my current mock-up looks like. > > rob > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- /david -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From david.obrien at redhat.com Tue Nov 6 15:57:53 2007 From: david.obrien at redhat.com (David O'Brien) Date: Wed, 07 Nov 2007 01:57:53 +1000 Subject: [Freeipa-devel] ipaserver-install and existing dirsrv instances Message-ID: <47308F01.2060506@redhat.com> Part of the requirements for installing freeipa-server is that there be no directory server instances. Just for a test, I ran the install script when there was an existing instance, and was asked whether I wanted to remove it. What happens if you don't, and attempt to use your existing dirsrv instance? Can you? What sort of configuration changes are required for dirsrv and/or ipa? thanks -- /david -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From rcritten at redhat.com Tue Nov 6 16:06:12 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 Nov 2007 11:06:12 -0500 Subject: [Freeipa-devel] ipaserver-install and existing dirsrv instances In-Reply-To: <47308F01.2060506@redhat.com> References: <47308F01.2060506@redhat.com> Message-ID: <473090F4.4020506@redhat.com> David O'Brien wrote: > Part of the requirements for installing freeipa-server is that there be > no directory server instances. Just for a test, I ran the install script > when there was an existing instance, and was asked whether I wanted to > remove it. > > What happens if you don't, and attempt to use your existing dirsrv > instance? Can you? What sort of configuration changes are required for > dirsrv and/or ipa? > > If you answer "no" to not remove it the installer quits. There is no way around it right now. 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 Nov 6 16:15:44 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 Nov 2007 11:15:44 -0500 Subject: [Freeipa-devel] GSSAPI Authorization error while trying to add a group In-Reply-To: <473021AB.8080503@redhat.com> References: <473021AB.8080503@redhat.com> Message-ID: <47309330.4040302@redhat.com> David O'Brien wrote: > Using freeipa-server from the 2007-11-05_10_07-build, I tried to add a > group: > Name: engineering > Description: all engineering dept. members > > and got the following: > > Group add failed: GSSAPI Authorization error > {'info': 'SASL(-1): generic failure: GSSAPI Error: Unspecified GSS > failure. Minor code may provide more information > (No such file or diectory)', 'desc':'Invalid credentials'} > > I'm logged in as admin. I'm trying to do this via the web interface. > haven't tried the commandline tools yet. > > I also tried with no description and got the same result. I didn't try > to add any members (haven't created any users yet). > > anyone else seen/tried this? You need to apply the patch to /etc/init.d/dirsrv found in http://freeipa.org/page/QuickInstall Apply that and restart FDS and it should work. 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 david.obrien at redhat.com Tue Nov 6 17:50:29 2007 From: david.obrien at redhat.com (David O'Brien) Date: Wed, 07 Nov 2007 03:50:29 +1000 Subject: [Freeipa-devel] which accounts to use in IPA Message-ID: <4730A965.6050106@redhat.com> When you run the freeipa-server-install, it creates/configures three accounts (possibly not the correct term for all); Directory Manager, Kerberos, and IPA admin. To run the web interface as Administrator and create users, etc., you get a Kerberos ticket (kinit admin) and point to the IPA server. That's fine... On the command line, who should I be logged in as to run ipa-*? Should I be doing all this as root? Seems like a bad idea. I can't log in as admin because it's not a "real" account (not an account on the box, only in IPA). Should I be adding /usr/sbin to the path of a regular user, or maybe creating a special user account for this? I also found it curious that I could log in as a regular user and create a new ipa user. Works for deluser too. So, if there is a krb ticket still valid on a machine, anyone could play havoc with ipa? Obviously I'm missing something... hmmm, 03:45. I probably should go to sleep and think about it tomorrow. -- /david -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From prowley at redhat.com Tue Nov 6 18:10:53 2007 From: prowley at redhat.com (Pete Rowley) Date: Tue, 06 Nov 2007 10:10:53 -0800 Subject: [Freeipa-devel] multi-valued fields In-Reply-To: <473089E3.8070406@redhat.com> References: <473089E3.8070406@redhat.com> Message-ID: <4730AE2D.8000107@redhat.com> Rob Crittenden wrote: > The multi-valued field problem is turning out to be a hard nut to > crack. I have a semi-working prototype now but I need to know which > attributes we will allow to be multi-valued. > cn, work number, fax number, cell number, pager number, home number, org unit, tags, car license, home page > > I've attached a screenshot of what my current mock-up looks like. Looks good. Would it be possible to remove the add link and have an extra blank field just appear when all the fields are filled? Ideally pressing tab or otherwise changing focus after entering a new value would have the new blank field appear with the cursor focus. That would make it a bit prettier and also I think a bit more usable. -- Pete -------------- 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 kmacmill at redhat.com Tue Nov 6 18:29:54 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 06 Nov 2007 13:29:54 -0500 Subject: [Freeipa-devel] ipaserver-install and existing dirsrv instances In-Reply-To: <473090F4.4020506@redhat.com> References: <47308F01.2060506@redhat.com> <473090F4.4020506@redhat.com> Message-ID: <1194373794.7740.3.camel@mahler.iad.redhat.com> On Tue, 2007-11-06 at 11:06 -0500, Rob Crittenden wrote: > David O'Brien wrote: > > Part of the requirements for installing freeipa-server is that there be > > no directory server instances. Just for a test, I ran the install script > > when there was an existing instance, and was asked whether I wanted to > > remove it. > > > > What happens if you don't, and attempt to use your existing dirsrv > > instance? Can you? What sort of configuration changes are required for > > dirsrv and/or ipa? > > > > > > If you answer "no" to not remove it the installer quits. There is no way > around it right now. > In theory - if you know what you are doing - you could have multiple directory instances. But as Rob says, we don't currently support that. Karl From rcritten at redhat.com Tue Nov 6 18:33:39 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 Nov 2007 13:33:39 -0500 Subject: [Freeipa-devel] multi-valued fields In-Reply-To: <4730AE2D.8000107@redhat.com> References: <473089E3.8070406@redhat.com> <4730AE2D.8000107@redhat.com> Message-ID: <4730B383.4010200@redhat.com> Pete Rowley wrote: > Rob Crittenden wrote: >> The multi-valued field problem is turning out to be a hard nut to >> crack. I have a semi-working prototype now but I need to know which >> attributes we will allow to be multi-valued. >> > cn, work number, fax number, cell number, pager number, home number, org > unit, tags, car license, home page Ouch, that's a lot of fields. Ok, I'll pick one and see if I can get multiples of these working at once. >> I've attached a screenshot of what my current mock-up looks like. > Looks good. Would it be possible to remove the add link and have an > extra blank field just appear when all the fields are filled? Ideally > pressing tab or otherwise changing focus after entering a new value > would have the new blank field appear with the cursor focus. That would > make it a bit prettier and also I think a bit more usable. Automatically adding a blank one I think would be confusing and would cause validation issues for required fields. I was thinking about using CSS to make the Add/Remove font a bit smaller and perhaps adding in the field name for Add (e.g. Add Common Name). But that'll come later, once I get the basic plumbing working. 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 Nov 6 19:29:00 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 Nov 2007 14:29:00 -0500 Subject: [Freeipa-devel] group inactivation question Message-ID: <4730C07C.9060508@redhat.com> Ticket https://hosted.fedoraproject.org/projects/freeipa/ticket/54 calls for an option to inactivate all users in a group. I've got this mostly done on the GUI side. I added a similar option to mark a group as active/inactive and it too updates nsAccountLock. So in XML-RPC when a group is updated I can see if this is "true" and mark all the members as inactive. But this opens a real can of works. Groups can be members of groups. Should I follow all paths and recursively mark everything inactive? And does the reverse hold true as well? If a group is inactive and it is marked active does that cause everything to become active again? I assume so but I hate assuming. 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 jdennis at redhat.com Tue Nov 6 21:11:18 2007 From: jdennis at redhat.com (John Dennis) Date: Tue, 06 Nov 2007 16:11:18 -0500 Subject: [Freeipa-devel] local DNS zone setup, please review Message-ID: <4730D876.1010601@redhat.com> I set up my own local DNS server to assure the forward and reverse DNS resolutions worked for my IPA test server, kerberos and possibly other IPA components will not work if this is not true. I am not a DNS guru, I muddled my way through it and got something working, but I'm not 100% I did things the right way. I think having this reviewed would be good and if it's acceptable I think we might want to document this in an IPA howto for developers. * the test server is sitting on a private lan with 192.168.1.0 addresses. * I named my domain ipatest.jrd (jrd are my initials). I used .jrd to prevent any conflicts * I edited /etc/named.conf added these two zones (the zone files are attached) zone "ipatest.jrd" IN { // this is the authoritative server for // ipatest.jrd info type master; file "ipatest.zone"; }; zone "1.168.192.in-addr.arpa" { // this is the authoritative server for // the 192.168.1.0 network type master; file "revp.192.168.1"; }; * I edited /etc/resolv.conf and replaced the two nameservers which had been defined there with 'nameserver localhost' * Back in /etc/named.conf I added: forwarders {1.2.3.4; 5.6.7.8;}; to the options section with the ip address of the name servers which had been in resolv.conf (1.2.3.4 and 5.6.7.8 for example here, they are our internal Red Hat DNS servers and I didn't think I should post those addresses). Issues/Questions: * Is forwarders the correct way to resolve locally first but then defer to other nameservers? At first I had tried to have my local nameserver and the existing nameservers in resolv.conf thinking if one failed it would try the next, but I don't think it works that way, I think the way it works is it tries the first one in the list and if there is no response it tries the next. The problem seemed to be that the first one in the list (localhost) responded with "I don't know" and no other nameservers were queried. So I added the forwarders to get the local nameserver to defer elsewhere. By the way, "public" addresses did resolve without forwarding, the local nameserver contacted the root as it should, but our Red Hat addresses were not getting resolved because the Red Hat DNS server was not getting queried. So is that the right way to handle that? * I use VPC which wants to write /etc/resolv.conf. I couldn't figure out how to get VPC not to trash /etc/resolv.conf (there seem to be some magic environment variables to control this) so in the vpnc init.d script I just wrote out a new resolv.conf with what I wanted. Yuck, but it works, there must be a better way. -- John Dennis -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ipatest.zone URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: revp.192.168.1 URL: From jdennis at redhat.com Tue Nov 6 21:30:34 2007 From: jdennis at redhat.com (John Dennis) Date: Tue, 06 Nov 2007 16:30:34 -0500 Subject: [Freeipa-devel] [PATCH] remove rpm, add radiusprofile Message-ID: <4730DCFA.4030800@redhat.com> This patch removes the use of rpm to query the package version. It also adds radiusprofile to the list of objectclasses used when creating a user. -- John Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: ipa.patch Type: text/x-patch Size: 5502 bytes Desc: not available URL: From rcritten at redhat.com Tue Nov 6 22:41:33 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 Nov 2007 17:41:33 -0500 Subject: [Freeipa-devel] account inactivation Message-ID: <4730ED9D.2010206@redhat.com> Ok, I'm working on the "deactivate a whole group" thing. I managed to get it working and inactivated a group. I can still get a ticket with those members but binding to LDAP returns: Account inactivated. Contact system administrator. Cool. Now how do I re-activate them? I deleted the nsAccountLock attribute but I still cannot connect to FDS. 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 Nov 6 22:55:49 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 06 Nov 2007 17:55:49 -0500 Subject: [Freeipa-devel] account inactivation In-Reply-To: <4730ED9D.2010206@redhat.com> References: <4730ED9D.2010206@redhat.com> Message-ID: <1194389749.5189.8.camel@hopeson> On Tue, 2007-11-06 at 17:41 -0500, Rob Crittenden wrote: > Ok, I'm working on the "deactivate a whole group" thing. > > I managed to get it working and inactivated a group. I can still get a > ticket with those members but binding to LDAP returns: I was looking into account inactivation on the flight, but the problem with kldap is that I couldn't find any attribute to do that (although I was sleepy I admit). I suspect there may be something in the data blob kldap sticks into ldap (bleah). > Account inactivated. Contact system administrator. > > Cool. > > Now how do I re-activate them? I deleted the nsAccountLock attribute but > I still cannot connect to FDS. Are you getting refused even after doing a new bind ? Simo. From ssorce at redhat.com Tue Nov 6 22:57:10 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 06 Nov 2007 17:57:10 -0500 Subject: [Freeipa-devel] local DNS zone setup, please review In-Reply-To: <4730D876.1010601@redhat.com> References: <4730D876.1010601@redhat.com> Message-ID: <1194389830.5189.10.camel@hopeson> On Tue, 2007-11-06 at 16:11 -0500, John Dennis wrote: > I am not a DNS guru, I muddled my way through it and got something > working, but I'm not 100% I did things the right way. I think having > this reviewed would be good and if it's acceptable I think we might > want > to document this in an IPA howto for developers. John have you seen the zone file sthat is generated by the setup script ? Or have you tried with --setup-bind ? Btw, Forwarders are the right way, stick more DNS servers in resolv.conf is *definitely* not. Simo. From rcritten at redhat.com Tue Nov 6 22:58:13 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 Nov 2007 17:58:13 -0500 Subject: [Freeipa-devel] account inactivation In-Reply-To: <1194389749.5189.8.camel@hopeson> References: <4730ED9D.2010206@redhat.com> <1194389749.5189.8.camel@hopeson> Message-ID: <4730F185.7040600@redhat.com> Simo Sorce wrote: > On Tue, 2007-11-06 at 17:41 -0500, Rob Crittenden wrote: >> Ok, I'm working on the "deactivate a whole group" thing. >> >> I managed to get it working and inactivated a group. I can still get a >> ticket with those members but binding to LDAP returns: > > I was looking into account inactivation on the flight, but the problem > with kldap is that I couldn't find any attribute to do that (although I > was sleepy I admit). > I suspect there may be something in the data blob kldap sticks into ldap > (bleah). > >> Account inactivated. Contact system administrator. >> >> Cool. >> >> Now how do I re-activate them? I deleted the nsAccountLock attribute but >> I still cannot connect to FDS. > > Are you getting refused even after doing a new bind ? > > Simo. > Right, I can get a ticket but can't use it. [rcrit at ipa ipa-gui]$ kinit rcrit Password for rcrit at GREYOAK.COM: [rcrit at ipa ipa-gui]$ ldapsearch -Y GSSAPI -b "dc=greyoak,dc=com" uid=rcrit SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Server is unwilling to perform (53) additional info: Account inactivated. Contact system administrator. -------------- 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 prowley at redhat.com Tue Nov 6 23:57:33 2007 From: prowley at redhat.com (Pete Rowley) Date: Tue, 06 Nov 2007 15:57:33 -0800 Subject: [Freeipa-devel] [PATCH] add single master posix uid/gid auto gen Message-ID: <4730FF6D.6040201@redhat.com> When KarlM checks in multi-master set up code I'll add the MMR part to this. -- Pete -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt 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 rcritten at redhat.com Wed Nov 7 03:18:06 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 Nov 2007 22:18:06 -0500 Subject: [Freeipa-devel] account inactivation In-Reply-To: <4730ED9D.2010206@redhat.com> References: <4730ED9D.2010206@redhat.com> Message-ID: <47312E6E.3090001@redhat.com> Rob Crittenden wrote: > Ok, I'm working on the "deactivate a whole group" thing. > > I managed to get it working and inactivated a group. I can still get a > ticket with those members but binding to LDAP returns: > > Account inactivated. Contact system administrator. > > Cool. > > Now how do I re-activate them? I deleted the nsAccountLock attribute but > I still cannot connect to FDS. > > rob Ok, turns out I hadn't actually removed the attribute. I forgot that one has to include that in the list of attributes when searching or it doesn't show up. I had actually added a second value of ''. Fixed by ldapmodify. It does show that the ipa-usermod --del command simply doesn't work though. I'll need to look more deeply at the way that the modlist is created so that deletes will work properly without inadvertently removing data in other cases. 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 david.obrien at redhat.com Wed Nov 7 08:02:31 2007 From: david.obrien at redhat.com (David O'Brien) Date: Wed, 07 Nov 2007 18:02:31 +1000 Subject: [Freeipa-devel] Help installing freeipa client? Message-ID: <47317117.50101@redhat.com> All of the following applies to 32 bit F7, each machine running in a VM. I installed freeipa-server ok, I can add users, etc. I used the --bind switch to create a local dns server for testing purposes. In another vm, I installed the client, but when I ran the config script, I ran into the following: 1. it couldn't determine the DNS domain, so I added it manually 2. Failed to find the IPA server name, so I added that manually 3. The script returned Ldap Error: {'desc': "Can't contact LDAP server"} Failed to verify that is and IPA Server, aborting. Additional info: Client machine: - $ hostname returns a fqdn - ping fqdn returns the "public" ip (not 127.0.0.1) - I can ping the IPA server by name and get the "public" ip - I added the IPA server ip to /etc/resolv.conf Server machine: - $ hostname returns a fqdn - ping fqdn returns the "public" ip (not 127.0.0.1) - ping the client by name returns "unknown host" - ping the client by ip is ok I notice that there is resolv.conf and resolve.conf on the server. The latter contains only info related to this configuration. Can anyone help get me going with this? Is there more DNS config that I need to do is more likely just a network issue? thanks -- /david -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jdennis at redhat.com Wed Nov 7 13:38:32 2007 From: jdennis at redhat.com (John Dennis) Date: Wed, 07 Nov 2007 08:38:32 -0500 Subject: [Freeipa-devel] which accounts to use in IPA In-Reply-To: <4730A965.6050106@redhat.com> References: <4730A965.6050106@redhat.com> Message-ID: <4731BFD8.6050803@redhat.com> David O'Brien wrote: > When you run the freeipa-server-install, it creates/configures three > accounts (possibly not the correct term for all); Directory Manager, > Kerberos, and IPA admin. > > To run the web interface as Administrator and create users, etc., you > get a Kerberos ticket (kinit admin) and point to the IPA server. That's > fine... > > On the command line, who should I be logged in as to run ipa-*? Should I > be doing all this as root? Seems like a bad idea. I can't log in as > admin because it's not a "real" account (not an account on the box, only > in IPA). Should I be adding /usr/sbin to the path of a regular user, or > maybe creating a special user account for this? The command line tools also require you to acquire an admin ticket via kinit just as you did above. There are no "login accounts" involved. > I also found it curious that I could log in as a regular user and create > a new ipa user. Works for deluser too. So, if there is a krb ticket > still valid on a machine, anyone could play havoc with ipa? Obviously > I'm missing something... hmmm, 03:45. I probably should go to sleep and > think about it tomorrow. If everything was working as it should you were able to add a user etc. as a "regular user" I presume because you had earlier acquired an admin ticket via kinit. This is beauty of single sign-on. You signed on once, you're good to go for the life of the ticket. If you don't the possibility of anyone walking up to your console and doing an unauthorized action then destroy your admin ticket via kdestroy. Poof, it's gone, you can't do anything again until the next successful kinit. -- John Dennis From rcritten at redhat.com Wed Nov 7 14:52:36 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 07 Nov 2007 09:52:36 -0500 Subject: [Freeipa-devel] [PATCH] post install memberof task In-Reply-To: <472FB5CF.6060103@redhat.com> References: <472FB5CF.6060103@redhat.com> Message-ID: <4731D134.8010904@redhat.com> Pete Rowley wrote: > Set off the task to initialize memberof for existing users. Is the ldif missing a changetype? 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 kmacmill at redhat.com Wed Nov 7 14:00:22 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Wed, 07 Nov 2007 09:00:22 -0500 Subject: [Freeipa-devel] which accounts to use in IPA In-Reply-To: <4730A965.6050106@redhat.com> References: <4730A965.6050106@redhat.com> Message-ID: <1194444022.3854.16.camel@localhost.localdomain> On Wed, 2007-11-07 at 03:50 +1000, David O'Brien wrote: > When you run the freeipa-server-install, it creates/configures three > accounts (possibly not the correct term for all); Directory Manager, > Kerberos, and IPA admin. > The kerberos "password" is really a master key. It is used to encrypt all of the key material that kerberos uses. There is no associated account. The Directory Manager is the "root" account for the directory. It is needed rarely (during multi-master setup for example), but is important. You will never "login" with this account or get a kerberos ticket with it. It is only used for direct ldap operations. The IPA admin is a powerful admin that we use to bootstrap IPA. The assumption is that this account will be used to create other accounts but not be used everyday. It also is the "root" account for keberos. > To run the web interface as Administrator and create users, etc., you > get a Kerberos ticket (kinit admin) and point to the IPA server. That's > fine... > But you should really only do that right after install. The first task should be to create a real account for the admin and give that the privileges it needs. > On the command line, who should I be logged in as to run ipa-*? Should I > be doing all this as root? Seems like a bad idea. No. > I can't log in as > admin because it's not a "real" account (not an account on the box, only > in IPA). Should I be adding /usr/sbin to the path of a regular user, or > maybe creating a special user account for this? > You can use a regular user account and you might add /usr/sbin to your path (I just run the tools with the full path). > I also found it curious that I could log in as a regular user and create > a new ipa user. Works for deluser too. So, if there is a krb ticket > still valid on a machine, anyone could play havoc with ipa? Obviously > I'm missing something... hmmm, 03:45. I probably should go to sleep and > think about it tomorrow. > That's likely because you have the admin kerberos ticket - the OS user and the kerberos user can be separate, and are when you have the admin ticket. In normal usage the user's OS user and kerberos user will be the same and likely won't have admin privileges with IPA. In v2 I think we might consider having users get a regular user account and an "admin" account - e.g., kmacmill at REALM and admin/kmacmill at REALM. Otherwise any malicious process running as the regular user can muck with IPA. Karl From kmacmill at redhat.com Wed Nov 7 14:02:22 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Wed, 07 Nov 2007 09:02:22 -0500 Subject: [Freeipa-devel] group inactivation question In-Reply-To: <4730C07C.9060508@redhat.com> References: <4730C07C.9060508@redhat.com> Message-ID: <1194444142.3854.19.camel@localhost.localdomain> On Tue, 2007-11-06 at 14:29 -0500, Rob Crittenden wrote: > Ticket https://hosted.fedoraproject.org/projects/freeipa/ticket/54 calls > for an option to inactivate all users in a group. > > I've got this mostly done on the GUI side. I added a similar option to > mark a group as active/inactive and it too updates nsAccountLock. > > So in XML-RPC when a group is updated I can see if this is "true" and > mark all the members as inactive. But this opens a real can of works. > > Groups can be members of groups. Should I follow all paths and > recursively mark everything inactive? > I say no - I think this behavior would be surprising, but who knows. > And does the reverse hold true as well? If a group is inactive and it is > marked active does that cause everything to become active again? I > assume so but I hate assuming. > I assume so as well. BTW - are you fixing the whole deluser is actually inactivation issue so that we can both delete users and inactivate them? Karl From kmacmill at redhat.com Wed Nov 7 14:06:00 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Wed, 07 Nov 2007 09:06:00 -0500 Subject: [Freeipa-devel] Help installing freeipa client? In-Reply-To: <47317117.50101@redhat.com> References: <47317117.50101@redhat.com> Message-ID: <1194444360.3854.23.camel@localhost.localdomain> On Wed, 2007-11-07 at 18:02 +1000, David O'Brien wrote: > All of the following applies to 32 bit F7, each machine running in a VM. > > I installed freeipa-server ok, I can add users, etc. I used the --bind > switch to create a local dns server for testing purposes. > > In another vm, I installed the client, but when I ran the config script, > I ran into the following: > > 1. it couldn't determine the DNS domain, so I added it manually > 2. Failed to find the IPA server name, so I added that manually > 3. The script returned Ldap Error: {'desc': "Can't contact LDAP server"} > Failed to verify that is and IPA Server, aborting. > > Additional info: > Client machine: > - $ hostname returns a fqdn > - ping fqdn returns the "public" ip (not 127.0.0.1) > - I can ping the IPA server by name and get the "public" ip > - I added the IPA server ip to /etc/resolv.conf > > Server machine: > - $ hostname returns a fqdn > - ping fqdn returns the "public" ip (not 127.0.0.1) > - ping the client by name returns "unknown host" > - ping the client by ip is ok > Did you allow the correct ports? > I notice that there is resolv.conf and resolve.conf on the server. The > latter contains only info related to this configuration. > So what is in resolv.conf? There should only be one (resolv.conf) and it should only have the ipa server. That might be the problem. Also - last I used the bind setup there was no reverse resolution. Without that I don't think things will work correctly. Also, did you add the client to dns? Karl From rcritten at redhat.com Wed Nov 7 15:25:06 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 07 Nov 2007 10:25:06 -0500 Subject: [Freeipa-devel] group inactivation question In-Reply-To: <1194444142.3854.19.camel@localhost.localdomain> References: <4730C07C.9060508@redhat.com> <1194444142.3854.19.camel@localhost.localdomain> Message-ID: <4731D8D2.9040006@redhat.com> Karl MacMillan wrote: > On Tue, 2007-11-06 at 14:29 -0500, Rob Crittenden wrote: >> Ticket https://hosted.fedoraproject.org/projects/freeipa/ticket/54 calls >> for an option to inactivate all users in a group. >> >> I've got this mostly done on the GUI side. I added a similar option to >> mark a group as active/inactive and it too updates nsAccountLock. >> >> So in XML-RPC when a group is updated I can see if this is "true" and >> mark all the members as inactive. But this opens a real can of works. >> >> Groups can be members of groups. Should I follow all paths and >> recursively mark everything inactive? >> > > I say no - I think this behavior would be surprising, but who knows. Well, I've assumed yes for now and have a recursive function that inactivates everything. Perhaps in the GUI I can bring up a dialog to confirm that this will be a recursive change. Would that be less surprising? >> And does the reverse hold true as well? If a group is inactive and it is >> marked active does that cause everything to become active again? I >> assume so but I hate assuming. >> > > I assume so as well. Ok, that's what I've done. > > BTW - are you fixing the whole deluser is actually inactivation issue so > that we can both delete users and inactivate them? I have a partial patch to at least fix some semantics. What I plan to do is update ipa-userdel to handle this, just haven't decided exactly how yet. We also lack a command-line re-activation tool (other than ipa-usermod --del=nsaccountlock ) I need to allow cmd-line group de-activation as well. Unfortunately I have totally hosed my development FDS instance which is making some testing difficult. I want to keep this instance around for future testing of fixes, so I'm kinda stuck. I wanted to make sure that my recursive function could exist so I added a set of circular groups (A member of B, B member of C, C member of A). Seems to have been a bad idea. 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 jdennis at redhat.com Wed Nov 7 15:55:33 2007 From: jdennis at redhat.com (John Dennis) Date: Wed, 07 Nov 2007 10:55:33 -0500 Subject: [Freeipa-devel] local DNS zone setup, please review In-Reply-To: <1194389830.5189.10.camel@hopeson> References: <4730D876.1010601@redhat.com> <1194389830.5189.10.camel@hopeson> Message-ID: <4731DFF5.7090607@redhat.com> Simo Sorce wrote: > John have you seen the zone file sthat is generated by the setup > script ? Or have you tried with --setup-bind ? Thanks, yes. FWIW it seems to me --setup-bind seems to be missing a few critical features, but perhaps I've missed something along the way. * setup-bind does not create a reverse zone, there are various operations in kerberos and probably other things as well which will fail in cryptic ways if the reverse mapping does not work. * it would be really nice if setup-bind could take into account other dns servers which might need to be queried, e.g. the corporate LAN (intranet) case. -- John Dennis From rcritten at redhat.com Wed Nov 7 19:37:21 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 07 Nov 2007 14:37:21 -0500 Subject: [Freeipa-devel] inactivating yourself Message-ID: <473213F1.1050803@redhat.com> Came across and intriguing problem when working on group inactivation. With group inactivation you pick a group, select inactive and update it. This causes all group members, including recursively all groups, to be marked inactive. So what should we do if the current user happens to be a member of that group (or subgroup)? What currently happens is IPA throws up because once the user is inactivated their credentials are no longer accepted by FDS. So should we: 1. Let things go ahead and blow up (i.e. change nothing) 2. Do not let them deactivate anything they are a part of 3. Do all the deactivation except for their record 4. Something else Ideas? I'm leaning towards #2 myself. 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 Nov 7 20:06:36 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 07 Nov 2007 15:06:36 -0500 Subject: [Freeipa-devel] [PATCH] add single master posix uid/gid auto gen In-Reply-To: <4730FF6D.6040201@redhat.com> References: <4730FF6D.6040201@redhat.com> Message-ID: <47321ACC.90405@redhat.com> Pete Rowley wrote: > When KarlM checks in multi-master set up code I'll add the MMR part to > this. > Looks good. 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 prowley at redhat.com Wed Nov 7 20:07:30 2007 From: prowley at redhat.com (Pete Rowley) Date: Wed, 07 Nov 2007 12:07:30 -0800 Subject: [Freeipa-devel] group inactivation question In-Reply-To: <4730C07C.9060508@redhat.com> References: <4730C07C.9060508@redhat.com> Message-ID: <47321B02.4070102@redhat.com> Rob Crittenden wrote: > Ticket https://hosted.fedoraproject.org/projects/freeipa/ticket/54 > calls for an option to inactivate all users in a group. > > I've got this mostly done on the GUI side. I added a similar option to > mark a group as active/inactive and it too updates nsAccountLock. > > So in XML-RPC when a group is updated I can see if this is "true" and > mark all the members as inactive. But this opens a real can of works. > > Groups can be members of groups. Should I follow all paths and > recursively mark everything inactive? > > And does the reverse hold true as well? If a group is inactive and it > is marked active does that cause everything to become active again? I > assume so but I hate assuming. There are a lot of problems doing this directly - using cos in the manner I described would have everything just work, including new users getting added to groups becoming inactivated and so on. -- Pete -------------- 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 rcritten at redhat.com Wed Nov 7 20:06:23 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 07 Nov 2007 15:06:23 -0500 Subject: [Freeipa-devel] [PATCH] remove rpm, add radiusprofile In-Reply-To: <4730DCFA.4030800@redhat.com> References: <4730DCFA.4030800@redhat.com> Message-ID: <47321ABF.7030600@redhat.com> John Dennis wrote: > This patch removes the use of rpm to query the package version. > It also adds radiusprofile to the list of objectclasses used when > creating a user. > Looks good. 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 Nov 7 20:07:58 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 07 Nov 2007 15:07:58 -0500 Subject: [Freeipa-devel] [PATCH] configure referential integrity plugin In-Reply-To: <472F651B.1090903@redhat.com> References: <472BAB0A.5000802@redhat.com> <1194190278.21823.72.camel@localhost.localdomain> <472F651B.1090903@redhat.com> Message-ID: <47321B1E.50108@redhat.com> Pete Rowley wrote: > Simo Sorce wrote: >> I see no patch attached .. >> >> > attached Will this maintain referencial integrity if a uid or cn is changed, esp in group membership? It looks like it only operates on the manager and secretary fields, or are those in addition to other stuff? 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 prowley at redhat.com Wed Nov 7 20:11:35 2007 From: prowley at redhat.com (Pete Rowley) Date: Wed, 07 Nov 2007 12:11:35 -0800 Subject: [Freeipa-devel] [PATCH] configure referential integrity plugin In-Reply-To: <47321B1E.50108@redhat.com> References: <472BAB0A.5000802@redhat.com> <1194190278.21823.72.camel@localhost.localdomain> <472F651B.1090903@redhat.com> <47321B1E.50108@redhat.com> Message-ID: <47321BF7.1060506@redhat.com> Rob Crittenden wrote: > Pete Rowley wrote: >> Simo Sorce wrote: >>> I see no patch attached .. >>> >>> >> attached > > Will this maintain referencial integrity if a uid or cn is changed, > esp in group membership? > yes the referint plugin deals with mod rdn > It looks like it only operates on the manager and secretary fields, or > are those in addition to other stuff? The plugin is preconfigured for all the other stuff we need. -- Pete -------------- 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 rcritten at redhat.com Wed Nov 7 20:13:06 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 07 Nov 2007 15:13:06 -0500 Subject: [Freeipa-devel] group inactivation question In-Reply-To: <47321B02.4070102@redhat.com> References: <4730C07C.9060508@redhat.com> <47321B02.4070102@redhat.com> Message-ID: <47321C52.3080504@redhat.com> Pete Rowley wrote: > Rob Crittenden wrote: >> Ticket https://hosted.fedoraproject.org/projects/freeipa/ticket/54 >> calls for an option to inactivate all users in a group. >> >> I've got this mostly done on the GUI side. I added a similar option to >> mark a group as active/inactive and it too updates nsAccountLock. >> >> So in XML-RPC when a group is updated I can see if this is "true" and >> mark all the members as inactive. But this opens a real can of works. >> >> Groups can be members of groups. Should I follow all paths and >> recursively mark everything inactive? >> >> And does the reverse hold true as well? If a group is inactive and it >> is marked active does that cause everything to become active again? I >> assume so but I hate assuming. > There are a lot of problems doing this directly - using cos in the > manner I described would have everything just work, including new users > getting added to groups becoming inactivated and so on. > Oh, I guess I missed that. I recall you asking if I used cos but not a description of how to use it. I'm open to not using brute-force. Can you explain cos again? I've never used it myself. thanks 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 prowley at redhat.com Wed Nov 7 20:14:42 2007 From: prowley at redhat.com (Pete Rowley) Date: Wed, 07 Nov 2007 12:14:42 -0800 Subject: [Freeipa-devel] [PATCH] post install memberof task In-Reply-To: <4731D134.8010904@redhat.com> References: <472FB5CF.6060103@redhat.com> <4731D134.8010904@redhat.com> Message-ID: <47321CB2.7020205@redhat.com> Rob Crittenden wrote: > Pete Rowley wrote: >> Set off the task to initialize memberof for existing users. > > Is the ldif missing a changetype? is it failing? -- Pete -------------- 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 rcritten at redhat.com Wed Nov 7 20:21:00 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 07 Nov 2007 15:21:00 -0500 Subject: [Freeipa-devel] [PATCH] post install memberof task In-Reply-To: <47321CB2.7020205@redhat.com> References: <472FB5CF.6060103@redhat.com> <4731D134.8010904@redhat.com> <47321CB2.7020205@redhat.com> Message-ID: <47321E2C.2000704@redhat.com> Pete Rowley wrote: > Rob Crittenden wrote: >> Pete Rowley wrote: >>> Set off the task to initialize memberof for existing users. >> >> Is the ldif missing a changetype? > is it failing? > I didn't try it but our call to ldapmodify doesn't include -a and the ldif doesn't have a changetype, so I assumed it would crap out. 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 jdennis at redhat.com Wed Nov 7 21:10:26 2007 From: jdennis at redhat.com (John Dennis) Date: Wed, 07 Nov 2007 16:10:26 -0500 Subject: [Freeipa-devel] expanding the LDAP tree Message-ID: <473229C2.3@redhat.com> I would like to add a new branch to our LDAP tree to store radius configuration information and I thought I would sanity check where I expect it belongs and how to add it. Yes/No/Comments welcome. I think the appropriate place is just under the suffix in a node called 'services' then each service can add their name below it and their data below that. For example: dn: cn=radius,cn=services,$SUFFIX dn: cn=clients,cn=radius,cn=services,$SUFFIX Sound reasonable? I also presume bootstrap-template.ldif is the place to create these, right? I also presume we would want to set an Admin Write ACL on cn=services,$SUFFIX and Read ACS on each of it's children limited to the service and admin. -- John Dennis From kmacmill at redhat.com Wed Nov 7 20:14:42 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Wed, 07 Nov 2007 15:14:42 -0500 Subject: [Freeipa-devel] expanding the LDAP tree In-Reply-To: <473229C2.3@redhat.com> References: <473229C2.3@redhat.com> Message-ID: <1194466482.19692.0.camel@cage.mentalrootkit.com> On Wed, 2007-11-07 at 16:10 -0500, John Dennis wrote: > I would like to add a new branch to our LDAP tree to store radius > configuration information and I thought I would sanity check where I > expect it belongs and how to add it. Yes/No/Comments welcome. > > I think the appropriate place is just under the suffix in a node called > 'services' then each service can add their name below it and their data > below that. For example: > > dn: cn=radius,cn=services,$SUFFIX > dn: cn=clients,cn=radius,cn=services,$SUFFIX > > Sound reasonable? > I'll let others comment in more detail, but we were already considering a services container to service kerberos entries. Karl From prowley at redhat.com Wed Nov 7 21:28:10 2007 From: prowley at redhat.com (Pete Rowley) Date: Wed, 07 Nov 2007 13:28:10 -0800 Subject: [Freeipa-devel] expanding the LDAP tree In-Reply-To: <473229C2.3@redhat.com> References: <473229C2.3@redhat.com> Message-ID: <47322DEA.50806@redhat.com> John Dennis wrote: > I would like to add a new branch to our LDAP tree to store radius > configuration information and I thought I would sanity check where I > expect it belongs and how to add it. Yes/No/Comments welcome. > > I think the appropriate place is just under the suffix in a node > called 'services' then each service can add their name below it and > their data below that. For example: > > dn: cn=radius,cn=services,$SUFFIX > dn: cn=clients,cn=radius,cn=services,$SUFFIX > ok > Sound reasonable? > > I also presume bootstrap-template.ldif is the place to create these, > right? > right > I also presume we would want to set an Admin Write ACL on > cn=services,$SUFFIX and Read ACS on each of it's children limited to > the service and admin. > Sounds good. -- Pete -------------- 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 jdennis at redhat.com Wed Nov 7 21:29:56 2007 From: jdennis at redhat.com (John Dennis) Date: Wed, 07 Nov 2007 16:29:56 -0500 Subject: [Freeipa-devel] expanding the LDAP tree In-Reply-To: <1194466482.19692.0.camel@cage.mentalrootkit.com> References: <473229C2.3@redhat.com> <1194466482.19692.0.camel@cage.mentalrootkit.com> Message-ID: <47322E54.9060408@redhat.com> Karl MacMillan wrote: > On Wed, 2007-11-07 at 16:10 -0500, John Dennis wrote: >> I would like to add a new branch to our LDAP tree to store radius >> configuration information and I thought I would sanity check where I >> expect it belongs and how to add it. Yes/No/Comments welcome. >> >> I think the appropriate place is just under the suffix in a node called >> 'services' then each service can add their name below it and their data >> below that. For example: >> >> dn: cn=radius,cn=services,$SUFFIX >> dn: cn=clients,cn=radius,cn=services,$SUFFIX >> >> Sound reasonable? >> > > I'll let others comment in more detail, but we were already considering > a services container to service kerberos entries. Opps, which just reminded me, I think that should have been: ou=services,$SUFFIX and not cn=services,$SUFFIX -- John Dennis From prowley at redhat.com Wed Nov 7 21:57:00 2007 From: prowley at redhat.com (Pete Rowley) Date: Wed, 07 Nov 2007 13:57:00 -0800 Subject: [Freeipa-devel] expanding the LDAP tree In-Reply-To: <47322E54.9060408@redhat.com> References: <473229C2.3@redhat.com> <1194466482.19692.0.camel@cage.mentalrootkit.com> <47322E54.9060408@redhat.com> Message-ID: <473234AC.30101@redhat.com> John Dennis wrote: > Karl MacMillan wrote: >> On Wed, 2007-11-07 at 16:10 -0500, John Dennis wrote: >>> I would like to add a new branch to our LDAP tree to store radius >>> configuration information and I thought I would sanity check where I >>> expect it belongs and how to add it. Yes/No/Comments welcome. >>> >>> I think the appropriate place is just under the suffix in a node >>> called 'services' then each service can add their name below it and >>> their data below that. For example: >>> >>> dn: cn=radius,cn=services,$SUFFIX >>> dn: cn=clients,cn=radius,cn=services,$SUFFIX >>> >>> Sound reasonable? >>> >> >> I'll let others comment in more detail, but we were already considering >> a services container to service kerberos entries. > > Opps, which just reminded me, I think that should have been: > > ou=services,$SUFFIX > > and not > > cn=services,$SUFFIX > no, we are not using ou, we are using cn (and objectclass nsContainer). Also, I think cn=services should be in cn=etc -- Pete -------------- 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 jdennis at redhat.com Wed Nov 7 23:06:29 2007 From: jdennis at redhat.com (John Dennis) Date: Wed, 07 Nov 2007 18:06:29 -0500 Subject: [Freeipa-devel] expanding the LDAP tree In-Reply-To: <473234AC.30101@redhat.com> References: <473229C2.3@redhat.com> <1194466482.19692.0.camel@cage.mentalrootkit.com> <47322E54.9060408@redhat.com> <473234AC.30101@redhat.com> Message-ID: <473244F5.70501@redhat.com> Pete Rowley wrote: > John Dennis wrote: >> ou=services,$SUFFIX > no, we are not using ou, we are using cn (and objectclass nsContainer). > Also, I think cn=services should be in cn=etc Sounds good, makes a lot sense, see that now, done, thanks. -- John Dennis From abartlet at samba.org Thu Nov 8 03:11:54 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Thu, 08 Nov 2007 14:11:54 +1100 Subject: [Freeipa-devel] How we should be integrating RADIUS Message-ID: <1194491514.13184.48.camel@naomi> I came across this HOWTO about RADIUS, and I think it explains very well why we need to have FreeRADIUS use Samba for MS-CHAP authentication. If we set it up right, this should 'just work' against the local Samba as a frontend to FreeIPA. http://wiki.freeradius.org/FreeRADIUS_Active_Directory_Integration_HOWTO I realise Samba isn't part of FreeIPA yet, but this just gives us another reason why it needs to be. I've looked over the patch for FreeIPA inclusion, but I can't quite see how to translate that into Samba (3) inclusion. 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 david.obrien at redhat.com Thu Nov 8 05:12:13 2007 From: david.obrien at redhat.com (David O'Brien) Date: Thu, 08 Nov 2007 15:12:13 +1000 Subject: [Freeipa-devel] Help installing freeipa client? In-Reply-To: <1194444360.3854.23.camel@localhost.localdomain> References: <47317117.50101@redhat.com> <1194444360.3854.23.camel@localhost.localdomain> Message-ID: <47329AAD.6040306@redhat.com> Karl MacMillan wrote: > On Wed, 2007-11-07 at 18:02 +1000, David O'Brien wrote: >> All of the following applies to 32 bit F7, each machine running in a VM. >> >> I installed freeipa-server ok, I can add users, etc. I used the --bind >> switch to create a local dns server for testing purposes. >> >> In another vm, I installed the client, but when I ran the config script, >> I ran into the following: >> >> 1. it couldn't determine the DNS domain, so I added it manually >> 2. Failed to find the IPA server name, so I added that manually >> 3. The script returned Ldap Error: {'desc': "Can't contact LDAP server"} >> Failed to verify that is and IPA Server, aborting. >> >> Additional info: >> Client machine: >> - $ hostname returns a fqdn >> - ping fqdn returns the "public" ip (not 127.0.0.1) >> - I can ping the IPA server by name and get the "public" ip >> - I added the IPA server ip to /etc/resolv.conf >> >> Server machine: >> - $ hostname returns a fqdn >> - ping fqdn returns the "public" ip (not 127.0.0.1) >> - ping the client by name returns "unknown host" >> - ping the client by ip is ok >> > > Did you allow the correct ports? > >> I notice that there is resolv.conf and resolve.conf on the server. The >> latter contains only info related to this configuration. >> > > So what is in resolv.conf? There should only be one (resolv.conf) and it > should only have the ipa server. That might be the problem. > > Also - last I used the bind setup there was no reverse resolution. > Without that I don't think things will work correctly. Also, did you add > the client to dns? > > Karl > > Hi Karl It was a combination of several of the above. I have dns working now (after a 3 - 4 hour self-training session ~!). When I run the ipa-client-install script now, I get an avc denial: SELinux is preventing the /usr/sbin/grpconv from using potentially mislabeled files (/root/ipaclient-install.log). I think I saw a patch somewhere about this... should log files be getting written to /temp or somewhere now? I probably need to point to a later build and yum update... -- /david -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From david.obrien at redhat.com Thu Nov 8 05:43:38 2007 From: david.obrien at redhat.com (David O'Brien) Date: Thu, 08 Nov 2007 15:43:38 +1000 Subject: [Freeipa-devel] Help installing freeipa client? In-Reply-To: <47329AAD.6040306@redhat.com> References: <47317117.50101@redhat.com> <1194444360.3854.23.camel@localhost.localdomain> <47329AAD.6040306@redhat.com> Message-ID: <4732A20A.9000004@redhat.com> David O'Brien wrote: > > Karl MacMillan wrote: >> On Wed, 2007-11-07 at 18:02 +1000, David O'Brien wrote: >>> All of the following applies to 32 bit F7, each machine running in a VM. >>> >>> I installed freeipa-server ok, I can add users, etc. I used the --bind >>> switch to create a local dns server for testing purposes. >>> >>> In another vm, I installed the client, but when I ran the config script, >>> I ran into the following: >>> >>> 1. it couldn't determine the DNS domain, so I added it manually >>> 2. Failed to find the IPA server name, so I added that manually >>> 3. The script returned Ldap Error: {'desc': "Can't contact LDAP server"} >>> Failed to verify that is and IPA Server, aborting. >>> >>> Additional info: >>> Client machine: >>> - $ hostname returns a fqdn >>> - ping fqdn returns the "public" ip (not 127.0.0.1) >>> - I can ping the IPA server by name and get the "public" ip >>> - I added the IPA server ip to /etc/resolv.conf >>> >>> Server machine: >>> - $ hostname returns a fqdn >>> - ping fqdn returns the "public" ip (not 127.0.0.1) >>> - ping the client by name returns "unknown host" >>> - ping the client by ip is ok >>> >> Did you allow the correct ports? >> >>> I notice that there is resolv.conf and resolve.conf on the server. The >>> latter contains only info related to this configuration. >>> >> So what is in resolv.conf? There should only be one (resolv.conf) and it >> should only have the ipa server. That might be the problem. >> >> Also - last I used the bind setup there was no reverse resolution. >> Without that I don't think things will work correctly. Also, did you add >> the client to dns? >> >> Karl >> >> > Hi Karl > It was a combination of several of the above. I have dns working now > (after a 3 - 4 hour self-training session ~!). > > When I run the ipa-client-install script now, I get an avc denial: > > SELinux is preventing the /usr/sbin/grpconv from using potentially > mislabeled files (/root/ipaclient-install.log). > > I think I saw a patch somewhere about this... should log files be > getting written to /temp or somewhere now? I probably need to point to > a later build and yum update... > > ok, I did yum update [1] but that didn't work (no matches to update). So I erased the packages and reinstalled to get later versions. I ran the install script again, Discovery was successful! (YAY) and it returned info about the realm, dns domain, etc., and finished by dropping me back to the shell prompt. I assume that means it worked? I still got the avc denial, however. A message at the end indicating a successful install or any issues would be comforting and/or useful. cheers [1] freeipa-admintools freeipa-client and freeipa-python -- /david -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From david.obrien at redhat.com Thu Nov 8 07:18:42 2007 From: david.obrien at redhat.com (David O'Brien) Date: Thu, 08 Nov 2007 17:18:42 +1000 Subject: [Freeipa-devel] freeipa-client configured but kerberos authentication error connecting to server Message-ID: <4732B852.2050600@redhat.com> I've just been through the HowTo for connecting a client to a server http://freeipa.org/page/How_to:RHEL4_setup (admittedly running on F7 here) ran into the following: 1. when I run kinit admin@ it appears to work except I receive only the krbtgt, not the http tcket. 2. I set up the negotiate attributes in Firefox, but get a Kerberos authentication error when I try to connect to the IPA server. Is 2. the result of 1.? How might I fix this? cheers -- /david -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From ssorce at redhat.com Thu Nov 8 14:39:47 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 08 Nov 2007 09:39:47 -0500 Subject: [Freeipa-devel] local DNS zone setup, please review In-Reply-To: <4731DFF5.7090607@redhat.com> References: <4730D876.1010601@redhat.com> <1194389830.5189.10.camel@hopeson> <4731DFF5.7090607@redhat.com> Message-ID: <1194532787.3271.2.camel@localhost.localdomain> On Wed, 2007-11-07 at 10:55 -0500, John Dennis wrote: > Simo Sorce wrote: > > John have you seen the zone file sthat is generated by the setup > > script ? Or have you tried with --setup-bind ? > > Thanks, yes. FWIW it seems to me --setup-bind seems to be missing a few > critical features, but perhaps I've missed something along the way. > > * setup-bind does not create a reverse zone, there are various > operations in kerberos and probably other things as well which will fail > in cryptic ways if the reverse mapping does not work. This seam easy and I will add it maybe, the problem being that you shadow any existing one this way and also that you must make sure the server is installed in the final subnet, not pretty. > * it would be really nice if setup-bind could take into account other > dns servers which might need to be queried, e.g. the corporate LAN > (intranet) case. This is not easy, how do you know where to find forwarders? Not sure trying to use the configured DNSs is a good idea (esp if you install on a test network and then you move the server. And I don't want to ask questions for now, we don;t support bind atm, admin has to check it anyway. Simo. From jdennis at redhat.com Thu Nov 8 14:51:02 2007 From: jdennis at redhat.com (John Dennis) Date: Thu, 08 Nov 2007 09:51:02 -0500 Subject: [Freeipa-devel] How we should be integrating RADIUS In-Reply-To: <1194491514.13184.48.camel@naomi> References: <1194491514.13184.48.camel@naomi> Message-ID: <47332256.9060207@redhat.com> Andrew Bartlett wrote: > I came across this HOWTO about RADIUS, and I think it explains very well > why we need to have FreeRADIUS use Samba for MS-CHAP authentication. > > If we set it up right, this should 'just work' against the local Samba > as a frontend to FreeIPA. > > http://wiki.freeradius.org/FreeRADIUS_Active_Directory_Integration_HOWTO > > I realise Samba isn't part of FreeIPA yet, but this just gives us > another reason why it needs to be. I've looked over the patch for > FreeIPA inclusion, but I can't quite see how to translate that into > Samba (3) inclusion. Thanks for the pointer Andrew, I'm familiar with the document. I'm sure at some point we may want to authenticate against AD but initially we're authenticating against IPA. There are many possible scenarios with how customers will want to use radius, our going in plan is to keep it simple for V1. One of the challenges of integrating radius into IPA is the fact radius is best thought of as a toolkit with multiple ways of setting it up tailored to the needs of the site. I think we're going to end up with a handful of pre-canned configurations that IPA supports, mschap/ntlm will will certainly be one of them in order to support Windows clients. Figuring out how we're going to handle mschap/ntlm is on hold till V2. -- John Dennis From ssorce at redhat.com Thu Nov 8 15:27:52 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 08 Nov 2007 10:27:52 -0500 Subject: [Freeipa-devel] expanding the LDAP tree In-Reply-To: <47322DEA.50806@redhat.com> References: <473229C2.3@redhat.com> <47322DEA.50806@redhat.com> Message-ID: <1194535672.3271.6.camel@localhost.localdomain> On Wed, 2007-11-07 at 13:28 -0800, Pete Rowley wrote: > John Dennis wrote: > > I would like to add a new branch to our LDAP tree to store radius > > configuration information and I thought I would sanity check where I > > expect it belongs and how to add it. Yes/No/Comments welcome. > > > > I think the appropriate place is just under the suffix in a node > > called 'services' then each service can add their name below it and > > their data below that. For example: > > > > dn: cn=radius,cn=services,$SUFFIX > > dn: cn=clients,cn=radius,cn=services,$SUFFIX > > > ok No, we have cn=etc for configuration of system services For clients I need to know what kind of info it is. Are these basically machine tickets? If so the info should be consolidated in the machine account under cn=computers IMO > > Sound reasonable? > > > > I also presume bootstrap-template.ldif is the place to create these, > > right? > > > right yes > > I also presume we would want to set an Admin Write ACL on > > cn=services,$SUFFIX and Read ACS on each of it's children limited to > > the service and admin. > > > Sounds good. yeah ACIs are needed, but probably in this case you should use the admins group, unless we need to explicitly reserve this for the uberAdmin Simo. From jdennis at redhat.com Thu Nov 8 16:02:09 2007 From: jdennis at redhat.com (John Dennis) Date: Thu, 08 Nov 2007 11:02:09 -0500 Subject: [Freeipa-devel] expanding the LDAP tree In-Reply-To: <1194535672.3271.6.camel@localhost.localdomain> References: <473229C2.3@redhat.com> <47322DEA.50806@redhat.com> <1194535672.3271.6.camel@localhost.localdomain> Message-ID: <47333301.9030806@redhat.com> Simo Sorce wrote: > No, we have cn=etc for configuration of system services > For clients I need to know what kind of info it is. > Are these basically machine tickets? > If so the info should be consolidated in the machine account under > cn=computers IMO I don't think this data falls under the category of computer with a ticket, but you could (forcibly) apply that interpretation if you wanted to. This is a list of NAS's (e.g. VPC concentrators, routers, etc.) being managed by radius. They don't have a krb ticket, but they do have a private authorization called a 'secret'. So they're similar but not the same. If they went under cn=computers,cn=accounts it would mean we would have non-homogeneous entries that would have to be distinguished by objectclass. That is unless there was another container node for devices of this class. But where would that container go? cn=nas,cn=computers,cn=accounts or cn=nas,cn=accounts? But that doesn't really make a lot of sense, they don't really have accounts in the sense I think we've applied to the notion 'account'. IMO, I think it makes sense for services who are mirroring their own internal data structures in LDAP to keep their data in their own part of the tree. That separation seems to make sense for a variety of reasons, simplicity, robustness, modularity, integrity, etc. But one could make a good argument for the other approach too. My suggestion would be to keep service data segregated in the tree, if it turns out to be an organizational problem we can revisit it later. -- John Dennis From ssorce at redhat.com Thu Nov 8 16:40:53 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 08 Nov 2007 11:40:53 -0500 Subject: [Freeipa-devel] expanding the LDAP tree In-Reply-To: <47333301.9030806@redhat.com> References: <473229C2.3@redhat.com> <47322DEA.50806@redhat.com> <1194535672.3271.6.camel@localhost.localdomain> <47333301.9030806@redhat.com> Message-ID: <1194540053.3271.11.camel@localhost.localdomain> On Thu, 2007-11-08 at 11:02 -0500, John Dennis wrote: > Simo Sorce wrote: > > No, we have cn=etc for configuration of system services > > For clients I need to know what kind of info it is. > > Are these basically machine tickets? > > If so the info should be consolidated in the machine account under > > cn=computers IMO > > I don't think this data falls under the category of computer with a > ticket, but you could (forcibly) apply that interpretation if you wanted to. > > This is a list of NAS's (e.g. VPC concentrators, routers, etc.) being > managed by radius. They don't have a krb ticket, but they do have a > private authorization called a 'secret'. So they're similar but not the > same. If they went under cn=computers,cn=accounts it would mean we would > have non-homogeneous entries that would have to be distinguished by > objectclass. That is unless there was another container node for devices > of this class. But where would that container go? > cn=nas,cn=computers,cn=accounts or cn=nas,cn=accounts? But that doesn't > really make a lot of sense, they don't really have accounts in the sense > I think we've applied to the notion 'account'. > > IMO, I think it makes sense for services who are mirroring their own > internal data structures in LDAP to keep their data in their own part of > the tree. That separation seems to make sense for a variety of reasons, > simplicity, robustness, modularity, integrity, etc. But one could make a > good argument for the other approach too. > > My suggestion would be to keep service data segregated in the tree, if > it turns out to be an organizational problem we can revisit it later. Explanation makes sense. Thank you. Simo. From abartlet at samba.org Thu Nov 8 20:25:19 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Fri, 09 Nov 2007 07:25:19 +1100 Subject: [Freeipa-devel] How we should be integrating RADIUS In-Reply-To: <47332256.9060207@redhat.com> References: <1194491514.13184.48.camel@naomi> <47332256.9060207@redhat.com> Message-ID: <1194553519.13184.93.camel@naomi> On Thu, 2007-11-08 at 09:51 -0500, John Dennis wrote: > Andrew Bartlett wrote: > > I came across this HOWTO about RADIUS, and I think it explains very well > > why we need to have FreeRADIUS use Samba for MS-CHAP authentication. > > > > If we set it up right, this should 'just work' against the local Samba > > as a frontend to FreeIPA. > > > > http://wiki.freeradius.org/FreeRADIUS_Active_Directory_Integration_HOWTO > > > > I realise Samba isn't part of FreeIPA yet, but this just gives us > > another reason why it needs to be. I've looked over the patch for > > FreeIPA inclusion, but I can't quite see how to translate that into > > Samba (3) inclusion. > > Thanks for the pointer Andrew, I'm familiar with the document. I'm sure > at some point we may want to authenticate against AD but initially we're > authenticating against IPA. There are many possible scenarios with how > customers will want to use radius, our going in plan is to keep it > simple for V1. You miss my point. The Samba part of this would be targeted at IPA (Samba as a DC against LDAP), not AD, and will handle MSCHAPv2 for FreeRADIUS. In all other respects, the configuration would be identical, as in both cases winbindd handles the details. > One of the challenges of integrating radius into IPA is the fact radius > is best thought of as a toolkit with multiple ways of setting it up > tailored to the needs of the site. Sure, but shouldn't the role of IPA be to provide all the backend configuration, already completed? > I think we're going to end up with a > handful of pre-canned configurations that IPA supports, mschap/ntlm will > will certainly be one of them in order to support Windows clients. > Figuring out how we're going to handle mschap/ntlm is on hold till V2. If it's any different to that HOWTO I'll be very surprised, but I look forward to it. 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 jdennis at redhat.com Thu Nov 8 21:26:58 2007 From: jdennis at redhat.com (John Dennis) Date: Thu, 08 Nov 2007 16:26:58 -0500 Subject: [Freeipa-devel] How we should be integrating RADIUS In-Reply-To: <1194553519.13184.93.camel@naomi> References: <1194491514.13184.48.camel@naomi> <47332256.9060207@redhat.com> <1194553519.13184.93.camel@naomi> Message-ID: <47337F22.204@redhat.com> Andrew Bartlett wrote: > You miss my point. The Samba part of this would be targeted at IPA > (Samba as a DC against LDAP), not AD, and will handle MSCHAPv2 for > FreeRADIUS. In all other respects, the configuration would be > identical, as in both cases winbindd handles the details. When samba is integrated with IPA as a DC we can do this but thats not the case today for v1. FWIW, a lot of the current IPA radius work has little to do with specific authentication methods but rather management of users and clients, that infrastructure has to be in place first. This is staged development, mschap is down the road. >> One of the challenges of integrating radius into IPA is the fact radius >> is best thought of as a toolkit with multiple ways of setting it up >> tailored to the needs of the site. > > Sure, but shouldn't the role of IPA be to provide all the backend > configuration, already completed? I'm afraid I don't follow what you mean by having all the backend configuration completed. >> I think we're going to end up with a >> handful of pre-canned configurations that IPA supports, mschap/ntlm will >> will certainly be one of them in order to support Windows clients. >> Figuring out how we're going to handle mschap/ntlm is on hold till V2. > > If it's any different to that HOWTO I'll be very surprised, but I look > forward to it. Yes you're right, for that one case it will look similar. What will be different from the HOWTO is all the places in the HOWTO where it says hand edit such and such, or where it fails to talk about the management of NAS devices or the management of per user NAS attributes, all of that infrastructure is getting automated as part of the v1 work. When that's done we can apply the HOWTO receipe. The initial goal is to avoid any direct manipulation of service configuration and the data the service needs to access, the HOWTO glosses over those issue with the presumption a human sys admin is actively involved in managing it. That's why mschap is slated for v2 not v1. -- John Dennis From abartlet at samba.org Thu Nov 8 21:33:39 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Fri, 09 Nov 2007 08:33:39 +1100 Subject: [Freeipa-devel] How we should be integrating RADIUS In-Reply-To: <47337F22.204@redhat.com> References: <1194491514.13184.48.camel@naomi> <47332256.9060207@redhat.com> <1194553519.13184.93.camel@naomi> <47337F22.204@redhat.com> Message-ID: <1194557619.13184.111.camel@naomi> On Thu, 2007-11-08 at 16:26 -0500, John Dennis wrote: > Andrew Bartlett wrote: > > You miss my point. The Samba part of this would be targeted at IPA > > (Samba as a DC against LDAP), not AD, and will handle MSCHAPv2 for > > FreeRADIUS. In all other respects, the configuration would be > > identical, as in both cases winbindd handles the details. > > When samba is integrated with IPA as a DC we can do this but thats not > the case today for v1. This I think is a big mistake (leaving Samba out of V1), but that's not where we are going for now. :-( > FWIW, a lot of the current IPA radius work has little to do with > specific authentication methods but rather management of users and > clients, that infrastructure has to be in place first. This is staged > development, mschap is down the road. OK. > >> One of the challenges of integrating radius into IPA is the fact radius > >> is best thought of as a toolkit with multiple ways of setting it up > >> tailored to the needs of the site. > > > > Sure, but shouldn't the role of IPA be to provide all the backend > > configuration, already completed? > > I'm afraid I don't follow what you mean by having all the backend > configuration completed. I mean the glue between FreeRADIUS and whatever it is using (Samba, krb5) to validate and authorise access. > >> I think we're going to end up with a > >> handful of pre-canned configurations that IPA supports, mschap/ntlm will > >> will certainly be one of them in order to support Windows clients. > >> Figuring out how we're going to handle mschap/ntlm is on hold till V2. > > > > If it's any different to that HOWTO I'll be very surprised, but I look > > forward to it. > > Yes you're right, for that one case it will look similar. What will be > different from the HOWTO is all the places in the HOWTO where it says > hand edit such and such, or where it fails to talk about the management > of NAS devices or the management of per user NAS attributes, all of that > infrastructure is getting automated as part of the v1 work. When that's > done we can apply the HOWTO receipe. The initial goal is to avoid any > direct manipulation of service configuration and the data the service > needs to access, the HOWTO glosses over those issue with the presumption > a human sys admin is actively involved in managing it. That's why mschap > is slated for v2 not v1. I look forward to seeing the progress here, in part because Samba4 will at some point probably need much the same treatment of FreeRADIUS. 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 rcritten at redhat.com Fri Nov 9 03:15:10 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 08 Nov 2007 22:15:10 -0500 Subject: [Freeipa-devel] [PATCH] Multi-valued field support Message-ID: <4733D0BE.9030008@redhat.com> This patch enables multi-value field support for some attributes on the edit pages (not the new pages). I punted on new because multiple values on the cn makes doing auto-suggest trickier. I'll come back to it. I improved error reporting in the GUI by printing the LDAP message as well. I also wrote up a short document describing how multi-valued fields work (so I don't forget later). Also attached is a required SRPM of the new widget. This RPM just re-packages an already packaged file. TG uses "egg" format for distributing stuff (zip file basically). My RPM just moves data around. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-366-multivalue.patch Type: text/x-patch Size: 45420 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TGExpandingFormWidget-0.1.3-1.fc7.src.rpm Type: application/x-redhat-package-manager Size: 7602 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 david.obrien at redhat.com Fri Nov 9 04:25:54 2007 From: david.obrien at redhat.com (David O'Brien) Date: Fri, 09 Nov 2007 14:25:54 +1000 Subject: [Freeipa-devel] Creating Delegations in IPA Message-ID: <4733E152.1090901@redhat.com> This was a bit confusing, but I think I know what is happening... When you add a delegation in IPA, it first asks for a Name. My first reaction was "who is the delegate?" but discovered that it means "What are you going to call this delegation?" + Suggestion: Delegation Name: Then, "People in Group" These are the people you're going to delegate certain tasks or abilities to. You don't delegate to a person, only a group. If you want to delegate to only one person, you have to create a group for that person. + Does it have to work this way? Could it not be "User or Group"? "For People in Group" I didn't realize straight off, but you can specify that the delegation only apply to specific groups. If you want to add a delegation that applies across everyone, you would have to create a group that contained everyone, right? There's probably a good reason that it works the way it does, but that was my initial reaction when I used it. Comments/elaborations? cheers -- /david -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From david.obrien at redhat.com Fri Nov 9 06:45:51 2007 From: david.obrien at redhat.com (David O'Brien) Date: Fri, 09 Nov 2007 16:45:51 +1000 Subject: [Freeipa-devel] logging in as different users? Message-ID: <4734021F.8080702@redhat.com> I tried the following on the IPA server: 1. kinit admin (got ticket ok) 2. Browse to server, interact, add a user. (all ok) 3. kdestroy 4. kinit newuser (got ticket ok) 5. Browse to server, interact. ok 6. kdestroy 7. kinit admin (checked revised ticket, ok) 8. Browse to server. It still says I'm logged in as newuser at domain I tried refreshing, closing the browser, etc., but I seem to be stuck. thanks for any suggestions -- /david -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From david.obrien at redhat.com Fri Nov 9 07:33:26 2007 From: david.obrien at redhat.com (David O'Brien) Date: Fri, 09 Nov 2007 17:33:26 +1000 Subject: [Freeipa-devel] logging in as different users? In-Reply-To: <4734021F.8080702@redhat.com> References: <4734021F.8080702@redhat.com> Message-ID: <47340D46.7050709@redhat.com> More information: I ssh'd to the server, ran kinit admin and browsed to the server using a different Firefox profile. Got logged in as admin A little while later (20mins) I closed the browser on the server itself, reopened and connected again, and now it says logged in as admin. So, I'm actually logged in to the IPA server as admin in two different locations. Does this open up the potential for collisions or is it a case of "First in is the winner"? What notification is there likely to be? I haven't tried anything yet... David O'Brien wrote: > I tried the following on the IPA server: > > 1. kinit admin (got ticket ok) > 2. Browse to server, interact, add a user. (all ok) > 3. kdestroy > 4. kinit newuser (got ticket ok) > 5. Browse to server, interact. ok > 6. kdestroy > 7. kinit admin (checked revised ticket, ok) > 8. Browse to server. It still says I'm logged in as newuser at domain > > I tried refreshing, closing the browser, etc., but I seem to be stuck. > > thanks for any suggestions > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- /david -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From rcritten at redhat.com Fri Nov 9 14:30:32 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 09 Nov 2007 09:30:32 -0500 Subject: [Freeipa-devel] Creating Delegations in IPA In-Reply-To: <4733E152.1090901@redhat.com> References: <4733E152.1090901@redhat.com> Message-ID: <47346F08.1000708@redhat.com> David O'Brien wrote: > This was a bit confusing, but I think I know what is happening... > > When you add a delegation in IPA, it first asks for a Name. My first > reaction was "who is the delegate?" but discovered that it means "What > are you going to call this delegation?" > > + Suggestion: Delegation Name: I know you're in the process of creating a trac account, this can be your first bug :-) > > Then, "People in Group" > These are the people you're going to delegate certain tasks or abilities > to. You don't delegate to a person, only a group. If you want to > delegate to only one person, you have to create a group for that person. > > + Does it have to work this way? Could it not be "User or Group"? Right now we only delegate to groups. If you want to delegate to a single person you'd have to create a new group, put that person in it, then delegate that. We're actually creating ACI's on the fly with this. From what I recall from when Kevin did this, adding support for user objects makes the parser exponentially more complex. > > "For People in Group" > I didn't realize straight off, but you can specify that the delegation > only apply to specific groups. If you want to add a delegation that > applies across everyone, you would have to create a group that contained > everyone, right? That is correct. > > There's probably a good reason that it works the way it does, but that > was my initial reaction when I used it. > > Comments/elaborations? > The current GUI has a slew of fields and check boxes. I have some ideas on how to make it easier to understand mostly by compressing things so you can more easily see that "oh, I'm saying let group A update attributes on group B and I'm going to call this thing a delegation." I have a task for this but not sure when I'll get to it: https://hosted.fedoraproject.org/projects/freeipa/ticket/87 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 Nov 9 14:47:46 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 09 Nov 2007 09:47:46 -0500 Subject: [Freeipa-devel] logging in as different users? In-Reply-To: <47340D46.7050709@redhat.com> References: <4734021F.8080702@redhat.com> <47340D46.7050709@redhat.com> Message-ID: <47347312.8070904@redhat.com> David O'Brien wrote: > More information: > > I ssh'd to the server, ran kinit admin and browsed to the server using a > different Firefox profile. Got logged in as admin > > A little while later (20mins) I closed the browser on the server itself, > reopened and connected again, and now it says logged in as admin. > > So, I'm actually logged in to the IPA server as admin in two different > locations. Does this open up the potential for collisions or is it a > case of "First in is the winner"? What notification is there likely to > be? I haven't tried anything yet... It's fine and perfectly valid. With simultaneous record updates the last one will win. rob > > David O'Brien wrote: >> I tried the following on the IPA server: >> >> 1. kinit admin (got ticket ok) >> 2. Browse to server, interact, add a user. (all ok) >> 3. kdestroy >> 4. kinit newuser (got ticket ok) >> 5. Browse to server, interact. ok >> 6. kdestroy >> 7. kinit admin (checked revised ticket, ok) >> 8. Browse to server. It still says I'm logged in as newuser at domain >> >> I tried refreshing, closing the browser, etc., but I seem to be stuck. >> >> thanks for any suggestions >> >> -------------- 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 kmacmill at redhat.com Fri Nov 9 15:33:17 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Fri, 09 Nov 2007 10:33:17 -0500 Subject: [Freeipa-devel] logging in as different users? In-Reply-To: <47347312.8070904@redhat.com> References: <4734021F.8080702@redhat.com> <47340D46.7050709@redhat.com> <47347312.8070904@redhat.com> Message-ID: <1194622397.3246.25.camel@clapton.mentalrootkit.com> On Fri, 2007-11-09 at 09:47 -0500, Rob Crittenden wrote: > David O'Brien wrote: > > More information: > > > > I ssh'd to the server, ran kinit admin and browsed to the server using a > > different Firefox profile. Got logged in as admin > > > > A little while later (20mins) I closed the browser on the server itself, > > reopened and connected again, and now it says logged in as admin. > > > > So, I'm actually logged in to the IPA server as admin in two different > > locations. Does this open up the potential for collisions or is it a > > case of "First in is the winner"? What notification is there likely to > > be? I haven't tried anything yet... > > It's fine and perfectly valid. With simultaneous record updates the last > one will win. > Maybe I misread things, but it sounds a bit like firefox was keeping tickets in memory allowing a user to auth after tickets were destroyed. Or did I misread that? Karl From kmacmill at redhat.com Fri Nov 9 15:35:35 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Fri, 09 Nov 2007 10:35:35 -0500 Subject: [Freeipa-devel] [PATCH] post install memberof task In-Reply-To: <47321E2C.2000704@redhat.com> References: <472FB5CF.6060103@redhat.com> <4731D134.8010904@redhat.com> <47321CB2.7020205@redhat.com> <47321E2C.2000704@redhat.com> Message-ID: <1194622535.3246.29.camel@clapton.mentalrootkit.com> On Wed, 2007-11-07 at 15:21 -0500, Rob Crittenden wrote: > Pete Rowley wrote: > > Rob Crittenden wrote: > >> Pete Rowley wrote: > >>> Set off the task to initialize memberof for existing users. > >> > >> Is the ldif missing a changetype? > > is it failing? > > > > > I didn't try it but our call to ldapmodify doesn't include -a and the > ldif doesn't have a changetype, so I assumed it would crap out. Pete - any resolution on this? Should I import the patch or not? Karl From ssorce at redhat.com Fri Nov 9 15:43:00 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 09 Nov 2007 10:43:00 -0500 Subject: [Freeipa-devel] logging in as different users? In-Reply-To: <1194622397.3246.25.camel@clapton.mentalrootkit.com> References: <4734021F.8080702@redhat.com> <47340D46.7050709@redhat.com> <47347312.8070904@redhat.com> <1194622397.3246.25.camel@clapton.mentalrootkit.com> Message-ID: <1194622980.3271.165.camel@localhost.localdomain> On Fri, 2007-11-09 at 10:33 -0500, Karl MacMillan wrote: > On Fri, 2007-11-09 at 09:47 -0500, Rob Crittenden wrote: > > David O'Brien wrote: > > > More information: > > > > > > I ssh'd to the server, ran kinit admin and browsed to the server using a > > > different Firefox profile. Got logged in as admin > > > > > > A little while later (20mins) I closed the browser on the server itself, > > > reopened and connected again, and now it says logged in as admin. > > > > > > So, I'm actually logged in to the IPA server as admin in two different > > > locations. Does this open up the potential for collisions or is it a > > > case of "First in is the winner"? What notification is there likely to > > > be? I haven't tried anything yet... > > > > It's fine and perfectly valid. With simultaneous record updates the last > > one will win. > > > > Maybe I misread things, but it sounds a bit like firefox was keeping > tickets in memory allowing a user to auth after tickets were destroyed. > Or did I misread that? I don't think this is possible, FF just uses the system libs and they don't do that. Simo. From kmacmill at redhat.com Fri Nov 9 15:55:10 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Fri, 09 Nov 2007 10:55:10 -0500 Subject: [Freeipa-devel] logging in as different users? In-Reply-To: <1194622980.3271.165.camel@localhost.localdomain> References: <4734021F.8080702@redhat.com> <47340D46.7050709@redhat.com> <47347312.8070904@redhat.com> <1194622397.3246.25.camel@clapton.mentalrootkit.com> <1194622980.3271.165.camel@localhost.localdomain> Message-ID: <1194623710.3246.40.camel@clapton.mentalrootkit.com> On Fri, 2007-11-09 at 10:43 -0500, Simo Sorce wrote: > On Fri, 2007-11-09 at 10:33 -0500, Karl MacMillan wrote: > > On Fri, 2007-11-09 at 09:47 -0500, Rob Crittenden wrote: > > > David O'Brien wrote: > > > > More information: > > > > > > > > I ssh'd to the server, ran kinit admin and browsed to the server using a > > > > different Firefox profile. Got logged in as admin > > > > > > > > A little while later (20mins) I closed the browser on the server itself, > > > > reopened and connected again, and now it says logged in as admin. > > > > > > > > So, I'm actually logged in to the IPA server as admin in two different > > > > locations. Does this open up the potential for collisions or is it a > > > > case of "First in is the winner"? What notification is there likely to > > > > be? I haven't tried anything yet... > > > > > > It's fine and perfectly valid. With simultaneous record updates the last > > > one will win. > > > > > > > Maybe I misread things, but it sounds a bit like firefox was keeping > > tickets in memory allowing a user to auth after tickets were destroyed. > > Or did I misread that? > > I don't think this is possible, FF just uses the system libs and they > don't do that. Well something is happening - look at his first report: I tried the following on the IPA server: 1. kinit admin (got ticket ok) 2. Browse to server, interact, add a user. (all ok) 3. kdestroy 4. kinit newuser (got ticket ok) 5. Browse to server, interact. ok 6. kdestroy 7. kinit admin (checked revised ticket, ok) 8. Browse to server. It still says I'm logged in as newuser at domain I tried refreshing, closing the browser, etc., but I seem to be stuck. Could be server-side, could be user error, but something odd is going on. Karl From kmacmill at redhat.com Fri Nov 9 15:58:56 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Fri, 09 Nov 2007 10:58:56 -0500 Subject: [Freeipa-devel] [PATCH] remove rpm, add radiusprofile In-Reply-To: <47321ABF.7030600@redhat.com> References: <4730DCFA.4030800@redhat.com> <47321ABF.7030600@redhat.com> Message-ID: <1194623936.3246.41.camel@clapton.mentalrootkit.com> On Wed, 2007-11-07 at 15:06 -0500, Rob Crittenden wrote: > John Dennis wrote: > > This patch removes the use of rpm to query the package version. > > It also adds radiusprofile to the list of objectclasses used when > > creating a user. > > > > Looks good. > Pushed. From kmacmill at redhat.com Fri Nov 9 15:59:28 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Fri, 09 Nov 2007 10:59:28 -0500 Subject: [Freeipa-devel] [PATCH] add single master posix uid/gid auto gen In-Reply-To: <47321ACC.90405@redhat.com> References: <4730FF6D.6040201@redhat.com> <47321ACC.90405@redhat.com> Message-ID: <1194623968.3246.43.camel@clapton.mentalrootkit.com> On Wed, 2007-11-07 at 15:06 -0500, Rob Crittenden wrote: > Pete Rowley wrote: > > When KarlM checks in multi-master set up code I'll add the MMR part to > > this. > > > > Looks good. Pushed. From kmacmill at redhat.com Fri Nov 9 16:15:51 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Fri, 09 Nov 2007 11:15:51 -0500 Subject: [Freeipa-devel] [PATCH] Multi-valued field support In-Reply-To: <4733D0BE.9030008@redhat.com> References: <4733D0BE.9030008@redhat.com> Message-ID: <1194624951.3246.50.camel@clapton.mentalrootkit.com> On Thu, 2007-11-08 at 22:15 -0500, Rob Crittenden wrote: > This patch enables multi-value field support for some attributes on the > edit pages (not the new pages). I punted on new because multiple values > on the cn makes doing auto-suggest trickier. I'll come back to it. > > I improved error reporting in the GUI by printing the LDAP message as well. > > I also wrote up a short document describing how multi-valued fields work > (so I don't forget later). > I reviewed this as well as I could and it looks ok. Should we push the config of which fields are multi-valued into ldap - whenever the ldap config gets done - or should we just leave them hard coded? > Also attached is a required SRPM of the new widget. This RPM just > re-packages an already packaged file. TG uses "egg" format for > distributing stuff (zip file basically). My RPM just moves data around. So this will be a separate rpm that we distribute? Or is this general enough that we should push it to Fedora? Or should we just push this widget into the ipa-server rpm? I'm thinking that we need to start version controlling all of the rpms that we may have to ship. Anyone have thoughts on this? Same repo as the rest of freeipa or a separate repo? I'll push this as soon as I understand how this should work. Karl From rcritten at redhat.com Fri Nov 9 16:24:48 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 09 Nov 2007 11:24:48 -0500 Subject: [Freeipa-devel] [PATCH] Multi-valued field support In-Reply-To: <1194624951.3246.50.camel@clapton.mentalrootkit.com> References: <4733D0BE.9030008@redhat.com> <1194624951.3246.50.camel@clapton.mentalrootkit.com> Message-ID: <473489D0.704@redhat.com> Karl MacMillan wrote: > On Thu, 2007-11-08 at 22:15 -0500, Rob Crittenden wrote: >> This patch enables multi-value field support for some attributes on the >> edit pages (not the new pages). I punted on new because multiple values >> on the cn makes doing auto-suggest trickier. I'll come back to it. >> >> I improved error reporting in the GUI by printing the LDAP message as well. >> >> I also wrote up a short document describing how multi-valued fields work >> (so I don't forget later). >> > > I reviewed this as well as I could and it looks ok. Should we push the > config of which fields are multi-valued into ldap - whenever the ldap > config gets done - or should we just leave them hard coded? No. If we used the standard TG template system we might be able to but currently the UI is hardcoded (so we have more control). > >> Also attached is a required SRPM of the new widget. This RPM just >> re-packages an already packaged file. TG uses "egg" format for >> distributing stuff (zip file basically). My RPM just moves data around. > > So this will be a separate rpm that we distribute? Or is this general > enough that we should push it to Fedora? Or should we just push this > widget into the ipa-server rpm? Ah, I suppose we could submit it to Fedora... For now I was thinking we'd carry it. I thought about including it in the main source but was thinking that it would make discrete upgrading difficult. > I'm thinking that we need to start version controlling all of the rpms > that we may have to ship. Anyone have thoughts on this? Same repo as the > rest of freeipa or a separate repo? > > I'll push this as soon as I understand how this should work. The risk of including it in the freepia repo is that if we include a large rpm package it could make source pulls a pain. Right now the code is very small which is nice. 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 rmeggins at redhat.com Fri Nov 9 16:32:12 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Fri, 09 Nov 2007 09:32:12 -0700 Subject: [Freeipa-devel] [PATCH] Multi-valued field support In-Reply-To: <1194624951.3246.50.camel@clapton.mentalrootkit.com> References: <4733D0BE.9030008@redhat.com> <1194624951.3246.50.camel@clapton.mentalrootkit.com> Message-ID: <47348B8C.2070001@redhat.com> Karl MacMillan wrote: > On Thu, 2007-11-08 at 22:15 -0500, Rob Crittenden wrote: > >> This patch enables multi-value field support for some attributes on the >> edit pages (not the new pages). I punted on new because multiple values >> on the cn makes doing auto-suggest trickier. I'll come back to it. >> >> I improved error reporting in the GUI by printing the LDAP message as well. >> >> I also wrote up a short document describing how multi-valued fields work >> (so I don't forget later). >> >> > > I reviewed this as well as I could and it looks ok. Should we push the > config of which fields are multi-valued into ldap - whenever the ldap > config gets done - or should we just leave them hard coded? > You could pull the information from the schema to see if the attribute is SINGLE-VALUED or not. > >> Also attached is a required SRPM of the new widget. This RPM just >> re-packages an already packaged file. TG uses "egg" format for >> distributing stuff (zip file basically). My RPM just moves data around. >> > > So this will be a separate rpm that we distribute? Or is this general > enough that we should push it to Fedora? Or should we just push this > widget into the ipa-server rpm? > > I'm thinking that we need to start version controlling all of the rpms > that we may have to ship. Anyone have thoughts on this? Same repo as the > rest of freeipa or a separate repo? > > I'll push this as soon as I understand how this should work. > > Karl > > _______________________________________________ > 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: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Nov 9 18:59:35 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 09 Nov 2007 13:59:35 -0500 Subject: [Freeipa-devel] [PATCH] require unique delegations Message-ID: <4734AE17.9090007@redhat.com> Require uniqueness in the name/comment field of delegations Fix error reporting in the UI to include the detailed message Sort delegations by name when displaying them Update the name field from "Name" to "Delegation Name" as suggested by David O'Brien rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-367-delegation.patch Type: text/x-patch Size: 8270 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 Fri Nov 9 19:02:05 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 09 Nov 2007 14:02:05 -0500 Subject: [Freeipa-devel] [PATCH] some minor group fixes Message-ID: <4734AEAD.9040000@redhat.com> This patch likely depends on the multi-value patch. Fixes an error when editing a group with a single-valued cn field. Some error messages were displaying e.detail instead of just the desc portion of that (so it was super ugly) rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-368-group.patch Type: text/x-patch Size: 1988 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 prowley at redhat.com Fri Nov 9 19:24:36 2007 From: prowley at redhat.com (Pete Rowley) Date: Fri, 09 Nov 2007 11:24:36 -0800 Subject: [Freeipa-devel] Creating Delegations in IPA In-Reply-To: <4733E152.1090901@redhat.com> References: <4733E152.1090901@redhat.com> Message-ID: <4734B3F4.4080601@redhat.com> David O'Brien wrote: > This was a bit confusing, but I think I know what is happening... > > When you add a delegation in IPA, it first asks for a Name. My first > reaction was "who is the delegate?" but discovered that it means "What > are you going to call this delegation?" > > + Suggestion: Delegation Name: > > Then, "People in Group" > These are the people you're going to delegate certain tasks or abilities > to. You don't delegate to a person, only a group. If you want to > delegate to only one person, you have to create a group for that person. > > + Does it have to work this way? Could it not be "User or Group"? > Any time you want to delegate some responsibility to a single user or over a single user you should be asking yourself what the relationship really is at the abstract level e.g. is this a local admin having the ability modify local people, an office manager allowed to change office fax numbers? People change, they leave, they change roles, but the role and it's abilities stay more or less the same, and should be the same for one person in that role, or the 3 people you need in that role next month. It is harder to maintain a directory access control system that has not had this level of thinking and just as hard when the thinking is done but not expressed in an easily digested (or portable) format. For example, the admin that inherits the system might not know why joe should be able to modify all of bills attributes, whereas IPA Engineering Manager being able to modify attributes of IPA Engineer gives some clues about why the aci is there and that it is justified. In addition, when joe gets promoted and is replaced by bob, there is no need to change anything about access control since when the group shuffle happens the right privileges shuffle with them. So in effect we are strongly discouraging the one off aci in order to save people from themselves. > "For People in Group" > I didn't realize straight off, but you can specify that the delegation > only apply to specific groups. If you want to add a delegation that > applies across everyone, you would have to create a group that contained > everyone, right? > We should probably allow certain default cases like "everyone" - we shouldn't need a group. > There's probably a good reason that it works the way it does, but that > was my initial reaction when I used it. > > Comments/elaborations? > > cheers > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Pete -------------- 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 prowley at redhat.com Fri Nov 9 19:30:27 2007 From: prowley at redhat.com (Pete Rowley) Date: Fri, 09 Nov 2007 11:30:27 -0800 Subject: [Freeipa-devel] [PATCH] post install memberof task In-Reply-To: <1194622535.3246.29.camel@clapton.mentalrootkit.com> References: <472FB5CF.6060103@redhat.com> <4731D134.8010904@redhat.com> <47321CB2.7020205@redhat.com> <47321E2C.2000704@redhat.com> <1194622535.3246.29.camel@clapton.mentalrootkit.com> Message-ID: <4734B553.508@redhat.com> Karl MacMillan wrote: >> I didn't try it but our call to ldapmodify doesn't include -a and the >> ldif doesn't have a changetype, so I assumed it would crap out. >> > > Pete - any resolution on this? Should I import the patch or not? > It worked ok when I tested it so lets import. -- Pete -------------- 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 rcritten at redhat.com Fri Nov 9 19:57:01 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 09 Nov 2007 14:57:01 -0500 Subject: [Freeipa-devel] [PATCH] Handle no credentials cache more gracefully Message-ID: <4734BB8D.4030401@redhat.com> Don't continue if a kerberos credentials cache is not available. This used to throw a really cryptic error because it was getting into the very old proxy code. Apache forked-model detection was incorrect. Both of these return an error instead of raising one (so the user gets feedback instead of a 500 error). rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-369-nouser.patch Type: text/x-patch Size: 2199 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 Fri Nov 9 20:46:23 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 09 Nov 2007 15:46:23 -0500 Subject: [Freeipa-devel] [PATCH] delete users on command-line Message-ID: <4734C71F.20003@redhat.com> Add the capability to completely delete a user from the database. The default remains to inactivate them. The UI already has the ability to delete users (as well as inactivate). I did a minor bit of testing to test referential integrity and in my little tests things worked as they should. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-366-delete.patch Type: text/x-patch Size: 2509 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 Fri Nov 9 21:35:08 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 09 Nov 2007 16:35:08 -0500 Subject: [Freeipa-devel] [PATCH] handle ldap.UNWILLING_TO_PERFORM Message-ID: <4734D28C.1090400@redhat.com> Handle ldap.UNWILLING_TO_PERFORM more gracefully. This is seen if you have an inactivated account and you try to do something. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-367-unwilling.patch Type: text/x-patch Size: 1356 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 Fri Nov 9 22:09:02 2007 From: jdennis at redhat.com (John Dennis) Date: Fri, 09 Nov 2007 17:09:02 -0500 Subject: [Freeipa-devel] LDAP TLS issues Message-ID: <4734DA7E.8030608@redhat.com> I need to set up attribute encryption for some of the radius data in the directory server. Attribute encryption only works if the connection is secure. So I tried to enable TLS in the radius LDAP module, but I'm having problems, perhaps someone could shed some light... 1) ldap_start_tls() it's failing because the certificate is self signed. I believe this can be fixed in one of two ways a) add the certificate the ds instance was signed with to the CA used by the client, but where is that certificate? b) configure ldap to accept self signed certificates via ldap_int_tls_config(NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, "allow"); That works, but overriding certificate verification seems like a bad idea. 2) If TLS is enabled then the GSSAPI SASL bind fails. Is GSSAPI SASL incompatible with TLS? Or is there a specific sequence when using the two together which has to be followed? 3) The DS Admin guide says you can also use GSSAPI for secure transport if you're using SASL. Well, I'm doing a GSSAPI SASL bind, does that mean I'm getting a secure transport in the process or do I have to enable that and if so how? -- John Dennis From rcritten at redhat.com Fri Nov 9 22:13:07 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 09 Nov 2007 17:13:07 -0500 Subject: [Freeipa-devel] LDAP TLS issues In-Reply-To: <4734DA7E.8030608@redhat.com> References: <4734DA7E.8030608@redhat.com> Message-ID: <4734DB73.2000703@redhat.com> John Dennis wrote: > I need to set up attribute encryption for some of the radius data in the > directory server. Attribute encryption only works if the connection is > secure. So I tried to enable TLS in the radius LDAP module, but I'm > having problems, perhaps someone could shed some light... > > 1) ldap_start_tls() it's failing because the certificate is self signed. > I believe this can be fixed in one of two ways > > a) add the certificate the ds instance was signed with to the CA used by > the client, but where is that certificate? > > b) configure ldap to accept self signed certificates via > ldap_int_tls_config(NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, "allow"); > > That works, but overriding certificate verification seems like a bad idea. You can import the cert from /usr/share/ipa/cacert.asc > 2) If TLS is enabled then the GSSAPI SASL bind fails. Is GSSAPI SASL > incompatible with TLS? Or is there a specific sequence when using the > two together which has to be followed? > > 3) The DS Admin guide says you can also use GSSAPI for secure transport > if you're using SASL. Well, I'm doing a GSSAPI SASL bind, does that mean > I'm getting a secure transport in the process or do I have to enable > that and if so how? IIRC you can't do GSSAPI over SSL with FDS. But the link is encrypted by the SASL connection anyway so it isn't in the clear. I tested this the hard way by using ssltap as a proxy between my client and the ldap server. Thank goodness for 'reset' :-) If SSL is an absolute requirement then perhaps we can do something with client authentication. The problem is tha the more certs we issue the more we need to keep track of when expiration time rolls around. Not a huge problem but just another thing to remember to do. 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 Fri Nov 9 22:41:09 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 09 Nov 2007 17:41:09 -0500 Subject: [Freeipa-devel] LDAP TLS issues In-Reply-To: <4734DA7E.8030608@redhat.com> References: <4734DA7E.8030608@redhat.com> Message-ID: <1194648069.3226.8.camel@localhost.localdomain> On Fri, 2007-11-09 at 17:09 -0500, John Dennis wrote: > > 3) The DS Admin guide says you can also use GSSAPI for secure > transport > if you're using SASL. Well, I'm doing a GSSAPI SASL bind, does that > mean > I'm getting a secure transport in the process or do I have to enable > that and if so how? SASL/GSSAPI already provides (strong) encryption, you shouldn't need TLS. It's either/or Anyway, why would you need to encrypt something in directory server? When you search these attributes you will get them back in clear, the encryption is useful only to protect the data in case someone steals the disk and even then only if the secret is manually entered at start-up I believe ... Care to elaborate more? Simo. From jdennis at redhat.com Fri Nov 9 23:20:13 2007 From: jdennis at redhat.com (John Dennis) Date: Fri, 09 Nov 2007 18:20:13 -0500 Subject: [Freeipa-devel] LDAP TLS issues In-Reply-To: <1194648069.3226.8.camel@localhost.localdomain> References: <4734DA7E.8030608@redhat.com> <1194648069.3226.8.camel@localhost.localdomain> Message-ID: <4734EB2D.8050107@redhat.com> Simo Sorce wrote: > On Fri, 2007-11-09 at 17:09 -0500, John Dennis wrote: > > SASL/GSSAPI already provides (strong) encryption, you shouldn't need > TLS. > It's either/or I thought, but perhaps I was wrong, with SASL establishing encrypted transport was optional and independent of the auth mech. Or is it the case with GSSAPI encrypted transport the default is to always use encrypted transport? Or am I wrong that the use of encrypted transport is is a configurable property in SASL? > Anyway, why would you need to encrypt something in directory server? > When you search these attributes you will get them back in clear, the > encryption is useful only to protect the data in case someone steals the > disk and even then only if the secret is manually entered at start-up I > believe ... > > Care to elaborate more? Sure, I think you missed last Wednesday meeting. I'm storing radius client information in LDAP. One of those attributes is a secret shared between the NAS and Radius server. The Radius server must have plaintext access to the secret. The secret will be protected by ACL's, however it was felt the additional step of encrypting that attribute in the database was prudent. The secret is best thought of as an encryption key used to encrypt parts of the network communication between a radius client and the radius server. The secret is NOT a user password. Each NAS has it's own secret. If the secret were compromised it would be possible to decrypt sniffed radius protocol and possibly gain access to user passwords used in the radius protocol. In a conventional freeRADIUS installation the client data is store in a flat file protected by standard UNIX DAC. If the IPA server machine were root compromised that flat file could be read, the same is true of the LDAP database which in our case is also holding those secrets. However, if the LDAP database encrypted those attributes it would be one extra layer of protection. I believe the LDAP encryption key is stored on the server as well, so I suppose if the machine were root compromised it wouldn't be any worse than having the secrets in a flat file, but the hassle factor of getting the LDAP encryption key and decrypting the database may be more than the low hanging fruit a typical attacker is willing to invest in. -- John Dennis From rmeggins at redhat.com Fri Nov 9 23:23:53 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Fri, 09 Nov 2007 16:23:53 -0700 Subject: [Freeipa-devel] LDAP TLS issues In-Reply-To: <4734EB2D.8050107@redhat.com> References: <4734DA7E.8030608@redhat.com> <1194648069.3226.8.camel@localhost.localdomain> <4734EB2D.8050107@redhat.com> Message-ID: <4734EC09.20102@redhat.com> John Dennis wrote: > Simo Sorce wrote: >> On Fri, 2007-11-09 at 17:09 -0500, John Dennis wrote: >> >> SASL/GSSAPI already provides (strong) encryption, you shouldn't need >> TLS. >> It's either/or > > I thought, but perhaps I was wrong, with SASL establishing encrypted > transport was optional and independent of the auth mech. Or is it the > case with GSSAPI encrypted transport the default is to always use > encrypted transport? Or am I wrong that the use of encrypted transport > is is a configurable property in SASL? Both the server and the client can specify the minssf I believe, and the security strength will be the maximum of these two. > >> Anyway, why would you need to encrypt something in directory server? >> When you search these attributes you will get them back in clear, the >> encryption is useful only to protect the data in case someone steals the >> disk and even then only if the secret is manually entered at start-up I >> believe ... >> >> Care to elaborate more? > > Sure, I think you missed last Wednesday meeting. I'm storing radius > client information in LDAP. One of those attributes is a secret shared > between the NAS and Radius server. The Radius server must have > plaintext access to the secret. The secret will be protected by > ACL's, however it was felt the additional step of encrypting that > attribute in the database was prudent. > > The secret is best thought of as an encryption key used to encrypt > parts of the network communication between a radius client and the > radius server. The secret is NOT a user password. Each NAS has it's > own secret. If the secret were compromised it would be possible to > decrypt sniffed radius protocol and possibly gain access to user > passwords used in the radius protocol. > > In a conventional freeRADIUS installation the client data is store in > a flat file protected by standard UNIX DAC. If the IPA server machine > were root compromised that flat file could be read, the same is true > of the LDAP database which in our case is also holding those secrets. > However, if the LDAP database encrypted those attributes it would be > one extra layer of protection. I believe the LDAP encryption key is > stored on the server as well, so I suppose if the machine were root > compromised it wouldn't be any worse than having the secrets in a flat > file, but the hassle factor of getting the LDAP encryption key and > decrypting the database may be more than the low hanging fruit a > typical attacker is willing to invest in. -------------- 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 Sat Nov 10 20:07:15 2007 From: ssorce at redhat.com (Simo Sorce) Date: Sat, 10 Nov 2007 15:07:15 -0500 Subject: [Freeipa-devel] LDAP TLS issues In-Reply-To: <4734EB2D.8050107@redhat.com> References: <4734DA7E.8030608@redhat.com> <1194648069.3226.8.camel@localhost.localdomain> <4734EB2D.8050107@redhat.com> Message-ID: <1194725235.3226.13.camel@localhost.localdomain> On Fri, 2007-11-09 at 18:20 -0500, John Dennis wrote: > Simo Sorce wrote: > > On Fri, 2007-11-09 at 17:09 -0500, John Dennis wrote: > > > > SASL/GSSAPI already provides (strong) encryption, you shouldn't need > > TLS. > > It's either/or > > I thought, but perhaps I was wrong, with SASL establishing encrypted > transport was optional and independent of the auth mech. Or is it the > case with GSSAPI encrypted transport the default is to always use > encrypted transport? Or am I wrong that the use of encrypted transport > is is a configurable property in SASL? We enforce encryption to accept a connection, so we should be ok. > > Anyway, why would you need to encrypt something in directory server? > > When you search these attributes you will get them back in clear, the > > encryption is useful only to protect the data in case someone steals the > > disk and even then only if the secret is manually entered at start-up I > > believe ... > > > > Care to elaborate more? > > Sure, I think you missed last Wednesday meeting. I'm storing radius > client information in LDAP. One of those attributes is a secret shared > between the NAS and Radius server. The Radius server must have plaintext > access to the secret. The secret will be protected by ACL's, however > it was felt the additional step of encrypting that attribute in the > database was prudent. > > The secret is best thought of as an encryption key used to encrypt parts > of the network communication between a radius client and the radius > server. The secret is NOT a user password. Each NAS has it's own secret. > If the secret were compromised it would be possible to decrypt sniffed > radius protocol and possibly gain access to user passwords used in the > radius protocol. > > In a conventional freeRADIUS installation the client data is store in a > flat file protected by standard UNIX DAC. If the IPA server machine were > root compromised that flat file could be read, the same is true of the > LDAP database which in our case is also holding those secrets. However, > if the LDAP database encrypted those attributes it would be one extra > layer of protection. I believe the LDAP encryption key is stored on the > server as well, so I suppose if the machine were root compromised it > wouldn't be any worse than having the secrets in a flat file, but the > hassle factor of getting the LDAP encryption key and decrypting the > database may be more than the low hanging fruit a typical attacker is > willing to invest in. Ok on this premise I will probably also encrypt the kerberos Master password that will be hold in the krbMKey attribute on the kerberos container (currently only on a file on disk). From david.obrien at redhat.com Sun Nov 11 13:42:59 2007 From: david.obrien at redhat.com (David O'Brien) Date: Sun, 11 Nov 2007 23:42:59 +1000 Subject: [Freeipa-devel] Creating Delegations in IPA In-Reply-To: <4734B3F4.4080601@redhat.com> References: <4733E152.1090901@redhat.com> <4734B3F4.4080601@redhat.com> Message-ID: <473706E3.3060409@redhat.com> Pete Rowley wrote: > David O'Brien wrote: >> This was a bit confusing, but I think I know what is happening... >> >> When you add a delegation in IPA, it first asks for a Name. My first >> reaction was "who is the delegate?" but discovered that it means "What >> are you going to call this delegation?" >> >> + Suggestion: Delegation Name: >> >> Then, "People in Group" >> These are the people you're going to delegate certain tasks or abilities >> to. You don't delegate to a person, only a group. If you want to >> delegate to only one person, you have to create a group for that person. >> >> + Does it have to work this way? Could it not be "User or Group"? >> > Any time you want to delegate some responsibility to a single user or > over a single user you should be asking yourself what the relationship > really is at the abstract level e.g. is this a local admin having the > ability modify local people, an office manager allowed to change office > fax numbers? People change, they leave, they change roles, but the role > and it's abilities stay more or less the same, and should be the same > for one person in that role, or the 3 people you need in that role next > month. > > It is harder to maintain a directory access control system that has not > had this level of thinking and just as hard when the thinking is done > but not expressed in an easily digested (or portable) format. For > example, the admin that inherits the system might not know why joe > should be able to modify all of bills attributes, whereas IPA > Engineering Manager being able to modify attributes of IPA Engineer > gives some clues about why the aci is there and that it is justified. In > addition, when joe gets promoted and is replaced by bob, there is no > need to change anything about access control since when the group > shuffle happens the right privileges shuffle with them. > > So in effect we are strongly discouraging the one off aci in order to > save people from themselves. Yes, this makes sense. When I write about this I'll be sure to include some examples that explain this. thanks >> "For People in Group" >> I didn't realize straight off, but you can specify that the delegation >> only apply to specific groups. If you want to add a delegation that >> applies across everyone, you would have to create a group that contained >> everyone, right? >> > We should probably allow certain default cases like "everyone" - we > shouldn't need a group. >> There's probably a good reason that it works the way it does, but that >> was my initial reaction when I used it. >> >> Comments/elaborations? >> >> cheers >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > -- David O'Brien RHCT PGP-KeyID: 0x443CBA7B -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From david.obrien at redhat.com Mon Nov 12 06:08:15 2007 From: david.obrien at redhat.com (David O'Brien) Date: Mon, 12 Nov 2007 16:08:15 +1000 Subject: [Freeipa-devel] Does credential checking take a long time? Message-ID: <4737EDCF.8050605@redhat.com> I haven't nailed this right down yet, but one of the things I do when I boot any of my ipa machines is to su - to check a couple of config files (they get rewritten by vpn). It takes anything up to a minute? to get a root prompt back. About 10 minutes after bootup, I get a message that my Kerberos credentials have expired. when I renew, I can su - and get a root prompt immediately. I'm running on 32bit F7 in a VM with 512M (host has 2G). Once I get past this stage, everything seems to be fine. I ran top to see what was happening, but load was less than 1.0, no apparent major memory hogs, etc. Any suggestions? -- David O'Brien RHCT PGP-KeyID: 0x443CBA7B -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From kmacmill at redhat.com Mon Nov 12 14:39:41 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Mon, 12 Nov 2007 09:39:41 -0500 Subject: [Freeipa-devel] Does credential checking take a long time? In-Reply-To: <4737EDCF.8050605@redhat.com> References: <4737EDCF.8050605@redhat.com> Message-ID: <1194878381.31944.14.camel@localhost.localdomain> On Mon, 2007-11-12 at 16:08 +1000, David O'Brien wrote: > I haven't nailed this right down yet, but one of the things I do when I > boot any of my ipa machines is to su - to check a couple of config files > (they get rewritten by vpn). > > It takes anything up to a minute? to get a root prompt back. About 10 > minutes after bootup, I get a message that my Kerberos credentials have > expired. when I renew, I can su - and get a root prompt immediately. > I believe that your system is trying to contact the kdc but can't until you make the config changes. So the delay is waiting for that timeout to occur. Any authentication will trigger this because of the pam krb5 module. Karl From gpaterno at redhat.com Mon Nov 12 15:02:54 2007 From: gpaterno at redhat.com (Giuseppe Paterno') Date: Mon, 12 Nov 2007 16:02:54 +0100 Subject: [Freeipa-devel] webUI question Message-ID: <47386B1E.9060009@redhat.com> Hi! Quick question about the webui: why does it requires the e-mail? And what's the "see also" field that is required? A user might be not human and might not have an email associated. ipa-adduser does not require these fields. Cheers, Gippa From gpaterno at redhat.com Mon Nov 12 15:07:49 2007 From: gpaterno at redhat.com (Giuseppe Paterno') Date: Mon, 12 Nov 2007 16:07:49 +0100 Subject: [Freeipa-devel] ipa-client-install Message-ID: <47386C45.7020803@redhat.com> Another question :-) Should the ipa-client-install create a local kerberos keytab and a corresponding entry in LDAP? So that an installation will allow ssh with GSS into the system. More, an LDAP entry can be useful to associate services to the machine, such as mail parameters, ... I do propose also to create a "find host" so that you can lookup/modify host information for further stuffs, such as host services in future. Thanks for your help! Cheers, Gippa From kmacmill at redhat.com Mon Nov 12 15:13:01 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Mon, 12 Nov 2007 10:13:01 -0500 Subject: [Freeipa-devel] ipa-client-install In-Reply-To: <47386C45.7020803@redhat.com> References: <47386C45.7020803@redhat.com> Message-ID: <1194880381.2935.1.camel@localhost.localdomain> On Mon, 2007-11-12 at 16:07 +0100, Giuseppe Paterno' wrote: > Another question :-) > Should the ipa-client-install create a local kerberos keytab and a > corresponding entry in LDAP? > So that an installation will allow ssh with GSS into the system. More, > an LDAP entry can be useful to associate services to the machine, such > as mail parameters, ... We are hoping to optionally do this in v1. The problem is that we can only do this for hosts w/ a stable hostname. Which is a very large problem if you ask me. > I do propose also to create a "find host" so that you can lookup/modify > host information for further stuffs, such as host services in future. Top of the v2 feature list :) Karl From rcritten at redhat.com Mon Nov 12 15:14:30 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Nov 2007 10:14:30 -0500 Subject: [Freeipa-devel] webUI question In-Reply-To: <47386B1E.9060009@redhat.com> References: <47386B1E.9060009@redhat.com> Message-ID: <47386DD6.3030200@redhat.com> Giuseppe Paterno' wrote: > Hi! Quick question about the webui: why does it requires the e-mail? > And what's the "see also" field that is required? > A user might be not human and might not have an email associated. > ipa-adduser does not require these fields. > Cheers, Some of it is just experimentation, particularly seeAlso. We want to be able to allow users to dynamically add attributes to the new/show/edit pages. Two are there now, seeAlso and o. As a demo one is required and one isn't. As for e-mail, I'm not sure. Simo raised a similar question and we never got it answered. 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 jdennis at redhat.com Mon Nov 12 15:38:34 2007 From: jdennis at redhat.com (John Dennis) Date: Mon, 12 Nov 2007 10:38:34 -0500 Subject: [Freeipa-devel] LDAP TLS issues In-Reply-To: <1194725235.3226.13.camel@localhost.localdomain> References: <4734DA7E.8030608@redhat.com> <1194648069.3226.8.camel@localhost.localdomain> <4734EB2D.8050107@redhat.com> <1194725235.3226.13.camel@localhost.localdomain> Message-ID: <4738737A.4060605@redhat.com> Simo Sorce wrote: > Ok on this premise I will probably also encrypt the kerberos Master > password that will be hold in the krbMKey attribute on the kerberos > container (currently only on a file on disk). Just a heads up, I've added a utility function to set ds plugin attributes. When I check the patch in you can use that to modify the encryption attribute. -- John Dennis From rcritten at redhat.com Mon Nov 12 19:24:49 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Nov 2007 14:24:49 -0500 Subject: [Freeipa-devel] [PATCH] Initial policy support Message-ID: <4738A881.3000309@redhat.com> Here is the shell of support for policy editing. While not really a pluggable architecture there is a main "Policy" page that will let one pick from a variety of choices (currently just IPA Policy). At some point we could populate this list from LDAP such it will be much easier to insert new forms (but it may still require some editing of files to have them loaded, I'm not sure yet). rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-368-policy.patch Type: text/x-patch Size: 16569 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 Nov 12 19:49:27 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Nov 2007 14:49:27 -0500 Subject: [Freeipa-devel] [PATCH] redirect web requests to FQDN Message-ID: <4738AE47.4090501@redhat.com> Redirect browser request to the FQDN of the server to avoid kerberos hostname issues. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-369-redirect.patch Type: text/x-patch Size: 1170 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 Mon Nov 12 20:09:33 2007 From: jdennis at redhat.com (John Dennis) Date: Mon, 12 Nov 2007 15:09:33 -0500 Subject: [Freeipa-devel] should server install be done in two stages? Message-ID: <4738B2FD.3050602@redhat.com> Let me throw out an idea, see if it rings true ... We seem to have a somewhat awkward install scenario that I think is in part due to the lack of a "post install" step, but maybe I'm just not understanding the architecture well enough. Here's the issues: We use LDAP for our backend, some ipa components need to modify the contents of our dirsrv instance or modify it's configuration. We have a nice interface in ipaldap.py for connecting to the server adding/modifying entries. But we're not using that interface during server install, I assume because we haven't bootstrapped far enough to be able to bind to our ds instance as the admin. But imagine if we had... Right now we're getting around this problem with a proliferation of ldif template files in /usr/share/ipa and passing them to /usr/bin/ldapmodify with the admin password. IMHO its a bit awkward, probably doesn't scale gracefully, and its probably not the best mechanism to take into account site wide defaults. I'm finding for the radius stuff, and I think this has general application, a lot of what I want to do to initially set things up is not really bootstrapping, rather it's things I'd like to do by calling our LDAP API (e.g. add/modify entries). I could use the LDAP API if we had completed the bootstrapping stage. Suppose IPA components were installed/instantiated in two steps instead of just one, bootstrap and postinstall. During bootstrap your component is called to do only what is necessary to instantiate itself. Such things might include creating a service principal and installing schema. Later your component is called for a postinstall step. At this point you're guaranteed the directory server is up and running, the kdc is up and running, and the necessary principals and keytabs have been created. You're then free to use the API we've created. It's also would be a great time to take into account site specific defaults which you might want to take into consideration as you finalize your installation configuration. What I've been finding is I need to implement things twice, once using bootstrap methodologies and once again as "normal" code, it's a unfortunate redundancy. Here is an example: Radius has profiles, we'll have an API which allows one to create and modify a profile. However, there needs to be an initial default profile. Right now the only way to create the initial default profile is with bootstrap ldif's, I can't call the API to create a profile and set it as the default :-( Also when the default profile was created it would be nice if it could take into account site defaults. This is why I feel like there is a stage missing during the install process. Thoughts, Comments? -- John Dennis From rcritten at redhat.com Mon Nov 12 20:15:33 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Nov 2007 15:15:33 -0500 Subject: [Freeipa-devel] [PATCH] underline sortable columns Message-ID: <4738B465.6090802@redhat.com> Sort columns will be underlined so the fact that they are sortable is more obvious. Restoring the up/down arrows to indicate sort order. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-370-sort.patch Type: text/x-patch Size: 1066 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 kmacmill at redhat.com Mon Nov 12 20:36:19 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Mon, 12 Nov 2007 15:36:19 -0500 Subject: [Freeipa-devel] should server install be done in two stages? In-Reply-To: <4738B2FD.3050602@redhat.com> References: <4738B2FD.3050602@redhat.com> Message-ID: <1194899779.6751.2.camel@clapton.mentalrootkit.com> On Mon, 2007-11-12 at 15:09 -0500, John Dennis wrote: > Let me throw out an idea, see if it rings true ... > > We seem to have a somewhat awkward install scenario that I think is in > part due to the lack of a "post install" step, but maybe I'm just not > understanding the architecture well enough. Here's the issues: > > We use LDAP for our backend, some ipa components need to modify the > contents of our dirsrv instance or modify it's configuration. We have a > nice interface in ipaldap.py for connecting to the server > adding/modifying entries. But we're not using that interface during > server install, I assume because we haven't bootstrapped far enough to > be able to bind to our ds instance as the admin. But imagine if we had... > > Right now we're getting around this problem with a proliferation of ldif > template files in /usr/share/ipa and passing them to /usr/bin/ldapmodify > with the admin password. IMHO its a bit awkward, probably doesn't scale > gracefully, and its probably not the best mechanism to take into account > site wide defaults. > > I'm finding for the radius stuff, and I think this has general > application, a lot of what I want to do to initially set things up is > not really bootstrapping, rather it's things I'd like to do by calling > our LDAP API (e.g. add/modify entries). I could use the LDAP API if we > had completed the bootstrapping stage. Suppose IPA components were > installed/instantiated in two steps instead of just one, bootstrap and > postinstall. > No reason to have the two-step process. After the DS instance is created - which is the first step - you are free to bind to the directory and make changes. In fact, the krb tools do just that and that's what I'm doing in the replication setup. All you need to do is to pass down the directory manager password to do the simple bind. Karl From rcritten at redhat.com Mon Nov 12 20:51:02 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Nov 2007 15:51:02 -0500 Subject: [Freeipa-devel] modRDN Message-ID: <4738BCB6.5070508@redhat.com> I have a ticket (#3) to allow the RDN to be modified. python-ldap has a modrdn function so I know that I *can* change it, just have an ordering question. The request may come with a slew of other changes as well (likely gn, sn and sn too). It might just be easier, because of the way we generate the list of changes, to do the other changes first and then the modrdn. Is there any reason to do one before the other? I assume that any attribute in the DN gets automatically changed during the modrdn operation. Is that correct? We already have the referential integrity plugin enabled so in theory I just have to worry about constructing the two updates properly and not an repercusions of them. Right? thanks 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 rmeggins at redhat.com Mon Nov 12 20:55:41 2007 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 12 Nov 2007 13:55:41 -0700 Subject: [Freeipa-devel] modRDN In-Reply-To: <4738BCB6.5070508@redhat.com> References: <4738BCB6.5070508@redhat.com> Message-ID: <4738BDCD.6080306@redhat.com> Rob Crittenden wrote: > I have a ticket (#3) to allow the RDN to be modified. > > python-ldap has a modrdn function so I know that I *can* change it, > just have an ordering question. > > The request may come with a slew of other changes as well (likely gn, > sn and sn too). It might just be easier, because of the way we > generate the list of changes, to do the other changes first and then > the modrdn. Is there any reason to do one before the other? > > I assume that any attribute in the DN gets automatically changed > during the modrdn operation. Is that correct? I'm not sure what you mean. > > We already have the referential integrity plugin enabled so in theory > I just have to worry about constructing the two updates properly and > not an repercusions of them. Right? It depends. By default, refint will rename the old DN to the new DN in the attributes member, uniquemember, owner, and seeAlso in all entries in your suffix/subtree. > > thanks > > 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: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Nov 12 20:59:51 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Nov 2007 15:59:51 -0500 Subject: [Freeipa-devel] modRDN In-Reply-To: <4738BDCD.6080306@redhat.com> References: <4738BCB6.5070508@redhat.com> <4738BDCD.6080306@redhat.com> Message-ID: <4738BEC7.7050505@redhat.com> Rich Megginson wrote: > Rob Crittenden wrote: >> I have a ticket (#3) to allow the RDN to be modified. >> >> python-ldap has a modrdn function so I know that I *can* change it, >> just have an ordering question. >> >> The request may come with a slew of other changes as well (likely gn, >> sn and sn too). It might just be easier, because of the way we >> generate the list of changes, to do the other changes first and then >> the modrdn. Is there any reason to do one before the other? >> >> I assume that any attribute in the DN gets automatically changed >> during the modrdn operation. Is that correct? > I'm not sure what you mean. My current entry is uid=me, dc=freeipa,dc=org I do a modrdn to uid=thenewme, dc=freeipa,dc=org Is uid an attribute simply because it is in the DN or is it stored separately in the DS? I'm assuming that I don't need to issue a change for uid. Is that a good assumption? >> >> We already have the referential integrity plugin enabled so in theory >> I just have to worry about constructing the two updates properly and >> not an repercusions of them. Right? > It depends. By default, refint will rename the old DN to the new DN in > the attributes member, uniquemember, owner, and seeAlso in all entries > in your suffix/subtree. And it'll fix up group membership I think? We have a couple of additional fields configured (manager & secretary). thanks 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 jdennis at redhat.com Mon Nov 12 21:08:36 2007 From: jdennis at redhat.com (John Dennis) Date: Mon, 12 Nov 2007 16:08:36 -0500 Subject: [Freeipa-devel] should server install be done in two stages? In-Reply-To: <1194899779.6751.2.camel@clapton.mentalrootkit.com> References: <4738B2FD.3050602@redhat.com> <1194899779.6751.2.camel@clapton.mentalrootkit.com> Message-ID: <4738C0D4.7020004@redhat.com> Karl MacMillan wrote: > No reason to have the two-step process. After the DS instance is created > - which is the first step - you are free to bind to the directory and > make changes. In fact, the krb tools do just that and that's what I'm > doing in the replication setup. All you need to do is to pass down the > directory manager password to do the simple bind. Are you talking about this idiom? def ldap_mod(fd, dn, pwd): args = ["/usr/bin/ldapmodify", "-h", "127.0.0.1", "-xv", "-D", dn, "-w", pwd, "-f", fd.name] run(args) If so that's what I'm saying creates redundancy. The same thing done with ldif templates later gets done with IPAdmin.add_entry() et. al. Why implement things twice? -- John Dennis From rmeggins at redhat.com Mon Nov 12 21:09:24 2007 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 12 Nov 2007 14:09:24 -0700 Subject: [Freeipa-devel] modRDN In-Reply-To: <4738BEC7.7050505@redhat.com> References: <4738BCB6.5070508@redhat.com> <4738BDCD.6080306@redhat.com> <4738BEC7.7050505@redhat.com> Message-ID: <4738C104.6090001@redhat.com> Rob Crittenden wrote: > Rich Megginson wrote: >> Rob Crittenden wrote: >>> I have a ticket (#3) to allow the RDN to be modified. >>> >>> python-ldap has a modrdn function so I know that I *can* change it, >>> just have an ordering question. >>> >>> The request may come with a slew of other changes as well (likely >>> gn, sn and sn too). It might just be easier, because of the way we >>> generate the list of changes, to do the other changes first and then >>> the modrdn. Is there any reason to do one before the other? >>> >>> I assume that any attribute in the DN gets automatically changed >>> during the modrdn operation. Is that correct? >> I'm not sure what you mean. > > My current entry is uid=me, dc=freeipa,dc=org > > I do a modrdn to uid=thenewme, dc=freeipa,dc=org > > Is uid an attribute simply because it is in the DN or is it stored > separately in the DS? It is stored separately. If you do not provide uid: thenewme in the modrdn request, I believe DS will add it automatically. You can also specify to delete the old rdn (uid: me) as part of the modrdn request. > > I'm assuming that I don't need to issue a change for uid. Is that a > good assumption? Yes. > >>> >>> We already have the referential integrity plugin enabled so in >>> theory I just have to worry about constructing the two updates >>> properly and not an repercusions of them. Right? >> It depends. By default, refint will rename the old DN to the new DN >> in the attributes member, uniquemember, owner, and seeAlso in all >> entries in your suffix/subtree. > > And it'll fix up group membership I think? Yes. That will either be the member or the uniqueMember attribute. > > We have a couple of additional fields configured (manager & secretary). Ok. Those will need to be added to the refint plugin configuration. NOTE that any attribute in this list (that is used, anyway) will need to be indexed for equality or refint performance will be very bad. > > thanks > > 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 kmacmill at redhat.com Mon Nov 12 21:13:04 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Mon, 12 Nov 2007 16:13:04 -0500 Subject: [Freeipa-devel] should server install be done in two stages? In-Reply-To: <4738C0D4.7020004@redhat.com> References: <4738B2FD.3050602@redhat.com> <1194899779.6751.2.camel@clapton.mentalrootkit.com> <4738C0D4.7020004@redhat.com> Message-ID: <1194901984.6751.4.camel@clapton.mentalrootkit.com> On Mon, 2007-11-12 at 16:08 -0500, John Dennis wrote: > Karl MacMillan wrote: > > > No reason to have the two-step process. After the DS instance is created > > - which is the first step - you are free to bind to the directory and > > make changes. In fact, the krb tools do just that and that's what I'm > > doing in the replication setup. All you need to do is to pass down the > > directory manager password to do the simple bind. > > Are you talking about this idiom? > No. > def ldap_mod(fd, dn, pwd): > args = ["/usr/bin/ldapmodify", "-h", "127.0.0.1", "-xv", "-D", dn, > "-w", pwd, "-f", fd.name] > run(args) > > If so that's what I'm saying creates redundancy. The same thing done > with ldif templates later gets done with IPAdmin.add_entry() et. al. > > Why implement things twice? > That's not what I'm saying - have the installer directly connect to the DS. Karl From david.obrien at redhat.com Tue Nov 13 01:40:04 2007 From: david.obrien at redhat.com (David O'Brien) Date: Tue, 13 Nov 2007 11:40:04 +1000 Subject: [Freeipa-devel] Does credential checking take a long time? In-Reply-To: <1194878381.31944.14.camel@localhost.localdomain> References: <4737EDCF.8050605@redhat.com> <1194878381.31944.14.camel@localhost.localdomain> Message-ID: <47390074.6010205@redhat.com> Karl MacMillan wrote: > On Mon, 2007-11-12 at 16:08 +1000, David O'Brien wrote: >> I haven't nailed this right down yet, but one of the things I do when I >> boot any of my ipa machines is to su - to check a couple of config files >> (they get rewritten by vpn). >> >> It takes anything up to a minute? to get a root prompt back. About 10 >> minutes after bootup, I get a message that my Kerberos credentials have >> expired. when I renew, I can su - and get a root prompt immediately. >> > > I believe that your system is trying to contact the kdc but can't until > you make the config changes. So the delay is waiting for that timeout to > occur. Any authentication will trigger this because of the pam krb5 > module. > > Karl > > yes, that makes sense, thanks. -- David O'Brien RHCT PGP-KeyID: 0x443CBA7B -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From david.obrien at redhat.com Tue Nov 13 03:43:33 2007 From: david.obrien at redhat.com (David O'Brien) Date: Tue, 13 Nov 2007 13:43:33 +1000 Subject: [Freeipa-devel] http vs https for connecting to ipa server Message-ID: <47391D65.4040606@redhat.com> I thought this worked before... When I wanted to connect to the server from the client, I just used http://fqdn and it auto switched to https:// Today I have to explicitly use https or I get a "can't connect to server" message. I'm logged in to the client as a non-admin user, got a ticket ok, etc. Running on 32bit F7 cheers -- David O'Brien RHCT PGP-KeyID: 0x443CBA7B -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From rcritten at redhat.com Tue Nov 13 03:45:39 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Nov 2007 22:45:39 -0500 Subject: [Freeipa-devel] http vs https for connecting to ipa server In-Reply-To: <47391D65.4040606@redhat.com> References: <47391D65.4040606@redhat.com> Message-ID: <47391DE3.3030501@redhat.com> David O'Brien wrote: > I thought this worked before... > > When I wanted to connect to the server from the client, I just used > http://fqdn and it auto switched to https:// > > Today I have to explicitly use https or I get a "can't connect to > server" message. > > I'm logged in to the client as a non-admin user, got a ticket ok, etc. > > Running on 32bit F7 > > Can you post /etc/httpd/conf.d/ipa.conf? 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 david.obrien at redhat.com Tue Nov 13 03:50:18 2007 From: david.obrien at redhat.com (David O'Brien) Date: Tue, 13 Nov 2007 13:50:18 +1000 Subject: [Freeipa-devel] http vs https for connecting to ipa server In-Reply-To: <47391DE3.3030501@redhat.com> References: <47391D65.4040606@redhat.com> <47391DE3.3030501@redhat.com> Message-ID: <47391EFA.4000103@redhat.com> Rob Crittenden wrote: > David O'Brien wrote: >> I thought this worked before... >> >> When I wanted to connect to the server from the client, I just used >> http://fqdn and it auto switched to https:// >> >> Today I have to explicitly use https or I get a "can't connect to >> server" message. >> >> I'm logged in to the client as a non-admin user, got a ticket ok, etc. >> >> Running on 32bit F7 >> >> > > Can you post /etc/httpd/conf.d/ipa.conf? > > rob here you go -- David O'Brien RHCT PGP-KeyID: 0x443CBA7B -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ipa.conf URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From rcritten at redhat.com Tue Nov 13 04:13:09 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Nov 2007 23:13:09 -0500 Subject: [Freeipa-devel] [PATCH] part one of allowing RDN changes Message-ID: <47392455.4040405@redhat.com> - Allow a user or group to change an attribute in its RDN - Add secretary to the list of indexes otherwise RDN changing could be slow - Port --addattr, --setattr and --delattr from usermod to groupmod One can do it via the command line with something like: % ipa-usermod --setattr=uid=joesomebody joenobody Doing this in the UI will take a bit more time and thought. I'm not sure I want it to be very easy to do this. I know I've hated my login at several companies I've worked for but have been told (it's our policy). So we should tread carefully. I'm thinking that this field may only be editable if you're in the admins group (in the UI only). Note that I am making certain assumptions such as users are distinguished by uid= and groups by cn=. That is the only part of the DN that one may change. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-371-rdn.patch Type: text/x-patch Size: 14560 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 david.obrien at redhat.com Tue Nov 13 06:06:18 2007 From: david.obrien at redhat.com (David O'Brien) Date: Tue, 13 Nov 2007 16:06:18 +1000 Subject: [Freeipa-devel] webUI question In-Reply-To: <47386DD6.3030200@redhat.com> References: <47386B1E.9060009@redhat.com> <47386DD6.3030200@redhat.com> Message-ID: <47393EDA.7090606@redhat.com> Rob Crittenden wrote: > Giuseppe Paterno' wrote: >> Hi! Quick question about the webui: why does it requires the e-mail? >> And what's the "see also" field that is required? >> A user might be not human and might not have an email associated. >> ipa-adduser does not require these fields. >> Cheers, > > Some of it is just experimentation, particularly seeAlso. We want to be > able to allow users to dynamically add attributes to the new/show/edit > pages. Two are there now, seeAlso and o. As a demo one is required and > one isn't. > > As for e-mail, I'm not sure. Simo raised a similar question and we never > got it answered. > > rob > If some users are not going to be human, it makes me wonder, is "People" and "Person" the correct terminology? Ought we use "User", especially considering the underlying commands are ipa-adduser, etc. -- David O'Brien RHCT PGP-KeyID: 0x443CBA7B -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From ssorce at redhat.com Tue Nov 13 14:17:24 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 13 Nov 2007 09:17:24 -0500 Subject: [Freeipa-devel] webUI question In-Reply-To: <47393EDA.7090606@redhat.com> References: <47386B1E.9060009@redhat.com> <47386DD6.3030200@redhat.com> <47393EDA.7090606@redhat.com> Message-ID: <1194963444.4104.0.camel@localhost.localdomain> On Tue, 2007-11-13 at 16:06 +1000, David O'Brien wrote: > Rob Crittenden wrote: > > Giuseppe Paterno' wrote: > >> Hi! Quick question about the webui: why does it requires the e-mail? > >> And what's the "see also" field that is required? > >> A user might be not human and might not have an email associated. > >> ipa-adduser does not require these fields. > >> Cheers, > > > > Some of it is just experimentation, particularly seeAlso. We want to be > > able to allow users to dynamically add attributes to the new/show/edit > > pages. Two are there now, seeAlso and o. As a demo one is required and > > one isn't. > > > > As for e-mail, I'm not sure. Simo raised a similar question and we never > > got it answered. > > > > rob > > > > If some users are not going to be human, it makes me wonder, is "People" > and "Person" the correct terminology? Ought we use "User", especially > considering the underlying commands are ipa-adduser, etc. Yes this is why I lobbied for cn=users and not ou=people :-) Simo. From rcritten at redhat.com Tue Nov 13 14:25:48 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 13 Nov 2007 09:25:48 -0500 Subject: [Freeipa-devel] http vs https for connecting to ipa server In-Reply-To: <47391EFA.4000103@redhat.com> References: <47391D65.4040606@redhat.com> <47391DE3.3030501@redhat.com> <47391EFA.4000103@redhat.com> Message-ID: <4739B3EC.1020202@redhat.com> David O'Brien wrote: > Rob Crittenden wrote: >> David O'Brien wrote: >>> I thought this worked before... >>> >>> When I wanted to connect to the server from the client, I just used >>> http://fqdn and it auto switched to https:// >>> >>> Today I have to explicitly use https or I get a "can't connect to >>> server" message. >>> >>> I'm logged in to the client as a non-admin user, got a ticket ok, etc. >>> >>> Running on 32bit F7 >>> >>> >> Can you post /etc/httpd/conf.d/ipa.conf? >> >> rob > here you go > > Wierd. It has the port forwarding there. Have you tried restarting Apache? What does Apache log when you get the "can't connect" error? What client are you using? 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 kmacmill at redhat.com Tue Nov 13 14:52:47 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 13 Nov 2007 09:52:47 -0500 Subject: [Freeipa-devel] webUI question In-Reply-To: <1194963444.4104.0.camel@localhost.localdomain> References: <47386B1E.9060009@redhat.com> <47386DD6.3030200@redhat.com> <47393EDA.7090606@redhat.com> <1194963444.4104.0.camel@localhost.localdomain> Message-ID: <1194965567.4950.1.camel@clapton.mentalrootkit.com> On Tue, 2007-11-13 at 09:17 -0500, Simo Sorce wrote: > On Tue, 2007-11-13 at 16:06 +1000, David O'Brien wrote: > > Rob Crittenden wrote: > > > Giuseppe Paterno' wrote: > > >> Hi! Quick question about the webui: why does it requires the e-mail? > > >> And what's the "see also" field that is required? > > >> A user might be not human and might not have an email associated. > > >> ipa-adduser does not require these fields. > > >> Cheers, > > > > > > Some of it is just experimentation, particularly seeAlso. We want to be > > > able to allow users to dynamically add attributes to the new/show/edit > > > pages. Two are there now, seeAlso and o. As a demo one is required and > > > one isn't. > > > > > > As for e-mail, I'm not sure. Simo raised a similar question and we never > > > got it answered. > > > > > > rob > > > > > > > If some users are not going to be human, it makes me wonder, is "People" > > and "Person" the correct terminology? Ought we use "User", especially > > considering the underlying commands are ipa-adduser, etc. > > Yes this is why I lobbied for cn=users and not ou=people :-) > I agree with this as well - it matches existing Unix terminology and our commandline tools. So I think we should change to cn=users and updated the web gui. Objections (other than more work)? Karl From rcritten at redhat.com Tue Nov 13 15:00:59 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 13 Nov 2007 10:00:59 -0500 Subject: [Freeipa-devel] password policy Message-ID: <4739BC2B.9040604@redhat.com> The mock-up I did of policy doesn't include anything for password policies (other than warning of expiration). What are we going to allow to configure? Is IPA going to use the FDS password policy or its own? As for expiration, what query do I need to do to determine if the password is within some range of expiring (e.g. the next 3 days). 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 Nov 13 15:10:30 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 13 Nov 2007 10:10:30 -0500 Subject: [Freeipa-devel] webUI question In-Reply-To: <1194965567.4950.1.camel@clapton.mentalrootkit.com> References: <47386B1E.9060009@redhat.com> <47386DD6.3030200@redhat.com> <47393EDA.7090606@redhat.com> <1194963444.4104.0.camel@localhost.localdomain> <1194965567.4950.1.camel@clapton.mentalrootkit.com> Message-ID: <4739BE66.7030401@redhat.com> Karl MacMillan wrote: > On Tue, 2007-11-13 at 09:17 -0500, Simo Sorce wrote: >> On Tue, 2007-11-13 at 16:06 +1000, David O'Brien wrote: >>> Rob Crittenden wrote: >>>> Giuseppe Paterno' wrote: >>>>> Hi! Quick question about the webui: why does it requires the e-mail? >>>>> And what's the "see also" field that is required? >>>>> A user might be not human and might not have an email associated. >>>>> ipa-adduser does not require these fields. >>>>> Cheers, >>>> Some of it is just experimentation, particularly seeAlso. We want to be >>>> able to allow users to dynamically add attributes to the new/show/edit >>>> pages. Two are there now, seeAlso and o. As a demo one is required and >>>> one isn't. >>>> >>>> As for e-mail, I'm not sure. Simo raised a similar question and we never >>>> got it answered. >>>> >>>> rob >>>> >>> If some users are not going to be human, it makes me wonder, is "People" >>> and "Person" the correct terminology? Ought we use "User", especially >>> considering the underlying commands are ipa-adduser, etc. >> Yes this is why I lobbied for cn=users and not ou=people :-) >> > > I agree with this as well - it matches existing Unix terminology and our > commandline tools. So I think we should change to cn=users and updated > the web gui. > > Objections (other than more work)? We already store into cn=users, just the UI need to be updated. If someone wants to file a trac for it I'll add it into the queue. Along those lines, should we be requiring e-mail address for users? I may submit a patch soon to disable the annoying required seeAlso as well, but it does serve as a nice reminder that there is still much work to be done related to loading configuration data from LDAP. 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 Nov 13 15:15:39 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 13 Nov 2007 10:15:39 -0500 Subject: [Freeipa-devel] webUI question In-Reply-To: <1194965567.4950.1.camel@clapton.mentalrootkit.com> References: <47386B1E.9060009@redhat.com> <47386DD6.3030200@redhat.com> <47393EDA.7090606@redhat.com> <1194963444.4104.0.camel@localhost.localdomain> <1194965567.4950.1.camel@clapton.mentalrootkit.com> Message-ID: <1194966939.4104.9.camel@localhost.localdomain> On Tue, 2007-11-13 at 09:52 -0500, Karl MacMillan wrote: > On Tue, 2007-11-13 at 09:17 -0500, Simo Sorce wrote: > > On Tue, 2007-11-13 at 16:06 +1000, David O'Brien wrote: > > > Rob Crittenden wrote: > > > > Giuseppe Paterno' wrote: > > > >> Hi! Quick question about the webui: why does it requires the e-mail? > > > >> And what's the "see also" field that is required? > > > >> A user might be not human and might not have an email associated. > > > >> ipa-adduser does not require these fields. > > > >> Cheers, > > > > > > > > Some of it is just experimentation, particularly seeAlso. We want to be > > > > able to allow users to dynamically add attributes to the new/show/edit > > > > pages. Two are there now, seeAlso and o. As a demo one is required and > > > > one isn't. > > > > > > > > As for e-mail, I'm not sure. Simo raised a similar question and we never > > > > got it answered. > > > > > > > > rob > > > > > > > > > > If some users are not going to be human, it makes me wonder, is "People" > > > and "Person" the correct terminology? Ought we use "User", especially > > > considering the underlying commands are ipa-adduser, etc. > > > > Yes this is why I lobbied for cn=users and not ou=people :-) > > > > I agree with this as well - it matches existing Unix terminology and our > commandline tools. So I think we should change to cn=users and updated > the web gui. > > Objections (other than more work)? Change? It's already cn=users unless someone changed it recently. Simo. From ssorce at redhat.com Tue Nov 13 15:23:44 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 13 Nov 2007 10:23:44 -0500 Subject: [Freeipa-devel] webUI question In-Reply-To: <4739BE66.7030401@redhat.com> References: <47386B1E.9060009@redhat.com> <47386DD6.3030200@redhat.com> <47393EDA.7090606@redhat.com> <1194963444.4104.0.camel@localhost.localdomain> <1194965567.4950.1.camel@clapton.mentalrootkit.com> <4739BE66.7030401@redhat.com> Message-ID: <1194967424.4104.19.camel@localhost.localdomain> On Tue, 2007-11-13 at 10:10 -0500, Rob Crittenden wrote: > We already store into cn=users, just the UI need to be updated. If > someone wants to file a trac for it I'll add it into the queue. Ack > Along those lines, should we be requiring e-mail address for users? I think we should not. Some accounts are service account and have no mail, and besides people may not want to store this information here, or may want to have someone (IT vs HR) else deal with it and requiring it at creation would make it difficult. > I may submit a patch soon to disable the annoying required seeAlso as > well, but it does serve as a nice reminder that there is still much > work > to be done related to loading configuration data from LDAP. Ack. Simo. From kmacmill at redhat.com Tue Nov 13 15:34:54 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 13 Nov 2007 10:34:54 -0500 Subject: [Freeipa-devel] webUI question In-Reply-To: <1194967424.4104.19.camel@localhost.localdomain> References: <47386B1E.9060009@redhat.com> <47386DD6.3030200@redhat.com> <47393EDA.7090606@redhat.com> <1194963444.4104.0.camel@localhost.localdomain> <1194965567.4950.1.camel@clapton.mentalrootkit.com> <4739BE66.7030401@redhat.com> <1194967424.4104.19.camel@localhost.localdomain> Message-ID: <1194968094.4950.21.camel@clapton.mentalrootkit.com> On Tue, 2007-11-13 at 10:23 -0500, Simo Sorce wrote: > On Tue, 2007-11-13 at 10:10 -0500, Rob Crittenden wrote: > > We already store into cn=users, just the UI need to be updated. If > > someone wants to file a trac for it I'll add it into the queue. > > Ack > > > Along those lines, should we be requiring e-mail address for users? > > I think we should not. Some accounts are service account and have no > mail, and besides people may not want to store this information here, or > may want to have someone (IT vs HR) else deal with it and requiring it > at creation would make it difficult. > As far as that goes, I think that as few required fields as possible is good. And for service accounts, we don't want a password, right? Just /sbin/nologin as a shell? Karl From ssorce at redhat.com Tue Nov 13 15:48:07 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 13 Nov 2007 10:48:07 -0500 Subject: [Freeipa-devel] webUI question In-Reply-To: <1194968094.4950.21.camel@clapton.mentalrootkit.com> References: <47386B1E.9060009@redhat.com> <47386DD6.3030200@redhat.com> <47393EDA.7090606@redhat.com> <1194963444.4104.0.camel@localhost.localdomain> <1194965567.4950.1.camel@clapton.mentalrootkit.com> <4739BE66.7030401@redhat.com> <1194967424.4104.19.camel@localhost.localdomain> <1194968094.4950.21.camel@clapton.mentalrootkit.com> Message-ID: <1194968887.4104.25.camel@localhost.localdomain> On Tue, 2007-11-13 at 10:34 -0500, Karl MacMillan wrote: > On Tue, 2007-11-13 at 10:23 -0500, Simo Sorce wrote: > > On Tue, 2007-11-13 at 10:10 -0500, Rob Crittenden wrote: > > > We already store into cn=users, just the UI need to be updated. If > > > someone wants to file a trac for it I'll add it into the queue. > > > > Ack > > > > > Along those lines, should we be requiring e-mail address for users? > > > > I think we should not. Some accounts are service account and have no > > mail, and besides people may not want to store this information here, or > > may want to have someone (IT vs HR) else deal with it and requiring it > > at creation would make it difficult. > > > > As far as that goes, I think that as few required fields as possible is > good. And for service accounts, we don't want a password, right? > Just /sbin/nologin as a shell? What password? The service will have it's own kerberos password of course. Simo. From kmacmill at redhat.com Tue Nov 13 15:55:39 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 13 Nov 2007 10:55:39 -0500 Subject: [Freeipa-devel] webUI question In-Reply-To: <1194968887.4104.25.camel@localhost.localdomain> References: <47386B1E.9060009@redhat.com> <47386DD6.3030200@redhat.com> <47393EDA.7090606@redhat.com> <1194963444.4104.0.camel@localhost.localdomain> <1194965567.4950.1.camel@clapton.mentalrootkit.com> <4739BE66.7030401@redhat.com> <1194967424.4104.19.camel@localhost.localdomain> <1194968094.4950.21.camel@clapton.mentalrootkit.com> <1194968887.4104.25.camel@localhost.localdomain> Message-ID: <1194969339.4950.29.camel@clapton.mentalrootkit.com> On Tue, 2007-11-13 at 10:48 -0500, Simo Sorce wrote: > On Tue, 2007-11-13 at 10:34 -0500, Karl MacMillan wrote: > > On Tue, 2007-11-13 at 10:23 -0500, Simo Sorce wrote: > > > On Tue, 2007-11-13 at 10:10 -0500, Rob Crittenden wrote: > > > > We already store into cn=users, just the UI need to be updated. If > > > > someone wants to file a trac for it I'll add it into the queue. > > > > > > Ack > > > > > > > Along those lines, should we be requiring e-mail address for users? > > > > > > I think we should not. Some accounts are service account and have no > > > mail, and besides people may not want to store this information here, or > > > may want to have someone (IT vs HR) else deal with it and requiring it > > > at creation would make it difficult. > > > > > > > As far as that goes, I think that as few required fields as possible is > > good. And for service accounts, we don't want a password, right? > > Just /sbin/nologin as a shell? > > What password? > The service will have it's own kerberos password of course. Hmmm - not certain about of course. What about services that don't need a keytab? We could just let those traditional daemon accounts be local accounts, but I wasn't certain what the best practice was there. Karl From ssorce at redhat.com Tue Nov 13 16:00:25 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 13 Nov 2007 11:00:25 -0500 Subject: [Freeipa-devel] password policy In-Reply-To: <4739BC2B.9040604@redhat.com> References: <4739BC2B.9040604@redhat.com> Message-ID: <1194969625.4104.32.camel@localhost.localdomain> On Tue, 2007-11-13 at 10:00 -0500, Rob Crittenden wrote: > The mock-up I did of policy doesn't include anything for password > policies (other than warning of expiration). > > What are we going to allow to configure? Is IPA going to use the FDS > password policy or its own? > > As for expiration, what query do I need to do to determine if the > password is within some range of expiring (e.g. the next 3 days). Currently I have code to use the kerberos schema defined attributes for password policy. We can think of using the DS attributes/objectclass for it, but that does not mean using the DS password policy. The code is not exposed to plugins and assumes password history being done in a very specific way. For expiration we have 2 attributes: krbPasswordExpiration krbPrincipalExpiration They are both in generalizedTime format Simo. From ssorce at redhat.com Tue Nov 13 16:11:16 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 13 Nov 2007 16:11:16 +0000 Subject: [Freeipa-devel] webUI question In-Reply-To: <1194969339.4950.29.camel@clapton.mentalrootkit.com> References: <47386B1E.9060009@redhat.com> <47386DD6.3030200@redhat.com> <47393EDA.7090606@redhat.com> <1194963444.4104.0.camel@localhost.localdomain> <1194965567.4950.1.camel@clapton.mentalrootkit.com> <4739BE66.7030401@redhat.com> <1194967424.4104.19.camel@localhost.localdomain> <1194968094.4950.21.camel@clapton.mentalrootkit.com> <1194968887.4104.25.camel@localhost.localdomain> <1194969339.4950.29.camel@clapton.mentalrootkit.com> Message-ID: <1194970276.4104.35.camel@localhost.localdomain> On Tue, 2007-11-13 at 10:55 -0500, Karl MacMillan wrote: > On Tue, 2007-11-13 at 10:48 -0500, Simo Sorce wrote: > > On Tue, 2007-11-13 at 10:34 -0500, Karl MacMillan wrote: > > > On Tue, 2007-11-13 at 10:23 -0500, Simo Sorce wrote: > > > > On Tue, 2007-11-13 at 10:10 -0500, Rob Crittenden wrote: > > > > > We already store into cn=users, just the UI need to be updated. If > > > > > someone wants to file a trac for it I'll add it into the queue. > > > > > > > > Ack > > > > > > > > > Along those lines, should we be requiring e-mail address for users? > > > > > > > > I think we should not. Some accounts are service account and have no > > > > mail, and besides people may not want to store this information here, or > > > > may want to have someone (IT vs HR) else deal with it and requiring it > > > > at creation would make it difficult. > > > > > > > > > > As far as that goes, I think that as few required fields as possible is > > > good. And for service accounts, we don't want a password, right? > > > Just /sbin/nologin as a shell? > > > > What password? > > The service will have it's own kerberos password of course. > > Hmmm - not certain about of course. What about services that don't need > a keytab? We could just let those traditional daemon accounts be local > accounts, but I wasn't certain what the best practice was there. We can't make them in ldap at this stage as they may require different fixed UID/GIDs on different distributions. For v1 we don't touch anything below UID 500. In any case for services that do not need a keytab you simply don't wnat to have a krbPrincipalName at all. To do that we will need explicit support in our tools. At this moment all accounts are created as kerberos accounts. Simo. From rcritten at redhat.com Tue Nov 13 16:15:39 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 13 Nov 2007 11:15:39 -0500 Subject: [Freeipa-devel] [PATCH] Restrict access to parts of the UI Message-ID: <4739CDAB.5070809@redhat.com> Restrict access to some parts of the UI to those in the admins group. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-373-restrict.patch Type: text/x-patch Size: 6050 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 Nov 13 17:37:05 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 13 Nov 2007 12:37:05 -0500 Subject: [Freeipa-devel] dna_plugin Message-ID: <4739E0C1.6050706@redhat.com> I finally got around to testing the uid/gid auto-generation thinger. I commented out the hardcoded uidnumber['501'] and adding a user automatically generates a uid. So that's good. But each user also needs a gidNumber. What should that value be? I don't think we've ever come to a resolution on that. 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 kmacmill at redhat.com Tue Nov 13 18:07:07 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 13 Nov 2007 13:07:07 -0500 Subject: [Freeipa-devel] [PATCH] post install memberof task In-Reply-To: <4734B553.508@redhat.com> References: <472FB5CF.6060103@redhat.com> <4731D134.8010904@redhat.com> <47321CB2.7020205@redhat.com> <47321E2C.2000704@redhat.com> <1194622535.3246.29.camel@clapton.mentalrootkit.com> <4734B553.508@redhat.com> Message-ID: <1194977227.9034.0.camel@clapton.mentalrootkit.com> On Fri, 2007-11-09 at 11:30 -0800, Pete Rowley wrote: > Karl MacMillan wrote: > >> I didn't try it but our call to ldapmodify doesn't include -a and the > >> ldif doesn't have a changetype, so I assumed it would crap out. > >> > > > > Pete - any resolution on this? Should I import the patch or not? > > > It worked ok when I tested it so lets import. > Doesn't work for me - I get: [14/11]: initializing group membership root : CRITICAL Failed to load memberof-conf.ldif: Command '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w box -f /tmp/tmp_sqh6R' returned non-zero exit status 32 Karl From kmacmill at redhat.com Tue Nov 13 18:10:36 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 13 Nov 2007 13:10:36 -0500 Subject: [Freeipa-devel] [PATCH] Allow setting of lib directory to correct non-rpm builds on x86_64 Message-ID: # HG changeset patch # User "Karl MacMillan " # Date 1194977427 18000 # Node ID bf49b683c8d145bf5e757b716791f116c9e81a5e # Parent 88eab4025284d2e7053b1ad29b93f498aa199378 Allow setting of lib directory to correct non-rpm builds on x86_64. With this patch you will need to run: make autogen LIBDIR=/usr/lib64 Also works for 'make all'. diff -r 88eab4025284 -r bf49b683c8d1 Makefile --- a/Makefile Tue Nov 06 15:57:15 2007 -0800 +++ b/Makefile Tue Nov 13 13:10:27 2007 -0500 @@ -35,18 +35,20 @@ CLI_TARBALL_PREFIX=$(PRJ_PREFIX)-client- CLI_TARBALL_PREFIX=$(PRJ_PREFIX)-client-$(CLI_VERSION) CLI_TARBALL=$(CLI_TARBALL_PREFIX).tgz +LIBDIR ?= /usr/lib + all: bootstrap-autogen @for subdir in $(SUBDIRS); do \ (cd $$subdir && $(MAKE) $@) || exit 1; \ done bootstrap-autogen: - cd ipa-server; if [ ! -e Makefile ]; then ./autogen.sh --prefix=/usr --sysconfdir=/etc; fi - cd ipa-client; if [ ! -e Makefile ]; then ./autogen.sh --prefix=/usr --sysconfdir=/etc; fi + cd ipa-server; if [ ! -e Makefile ]; then ./autogen.sh --prefix=/usr --sysconfdir=/etc --libdir=$(LIBDIR); fi + cd ipa-client; if [ ! -e Makefile ]; then ./autogen.sh --prefix=/usr --sysconfdir=/etc --libdir=$(LIBDIR); fi autogen: - cd ipa-server; ./autogen.sh --prefix=/usr --sysconfdir=/etc; - cd ipa-client; ./autogen.sh --prefix=/usr --sysconfdir=/etc; + cd ipa-server; ./autogen.sh --prefix=/usr --sysconfdir=/etc --libdir=$(LIBDIR) + cd ipa-client; ./autogen.sh --prefix=/usr --sysconfdir=/etc --libdir=$(LIBDIR) configure: cd ipa-server; ./configure --prefix=/usr --sysconfdir=/etc From ssorce at redhat.com Tue Nov 13 18:28:44 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 13 Nov 2007 13:28:44 -0500 Subject: [Freeipa-devel] dna_plugin In-Reply-To: <4739E0C1.6050706@redhat.com> References: <4739E0C1.6050706@redhat.com> Message-ID: <1194978524.4104.39.camel@localhost.localdomain> On Tue, 2007-11-13 at 12:37 -0500, Rob Crittenden wrote: > I finally got around to testing the uid/gid auto-generation thinger. > > I commented out the hardcoded uidnumber['501'] and adding a user > automatically generates a uid. So that's good. > > But each user also needs a gidNumber. What should that value be? I don't > think we've ever come to a resolution on that. it depends on whether we want to keep doing the insane thing the OS does (ie a group for each user by default) in which case we should also create that group (bleah) an make gid == uid, or use a more saner default, create a "Users" group and make that be their default primary group on creation. Simo. From rcritten at redhat.com Tue Nov 13 18:41:06 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 13 Nov 2007 13:41:06 -0500 Subject: [Freeipa-devel] [PATCH] Allow setting of lib directory to correct non-rpm builds on x86_64 In-Reply-To: References: Message-ID: <4739EFC2.3010401@redhat.com> Karl MacMillan wrote: > # HG changeset patch > # User "Karl MacMillan " > # Date 1194977427 18000 > # Node ID bf49b683c8d145bf5e757b716791f116c9e81a5e > # Parent 88eab4025284d2e7053b1ad29b93f498aa199378 > Allow setting of lib directory to correct non-rpm builds on x86_64. > > With this patch you will need to run: > make autogen LIBDIR=/usr/lib64 > Also works for 'make all'. Ok. Did you want the rpm building to use this method too? 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 kmacmill at redhat.com Tue Nov 13 19:04:17 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 13 Nov 2007 14:04:17 -0500 Subject: [Freeipa-devel] dna_plugin In-Reply-To: <1194978524.4104.39.camel@localhost.localdomain> References: <4739E0C1.6050706@redhat.com> <1194978524.4104.39.camel@localhost.localdomain> Message-ID: <1194980657.9034.2.camel@clapton.mentalrootkit.com> On Tue, 2007-11-13 at 13:28 -0500, Simo Sorce wrote: > On Tue, 2007-11-13 at 12:37 -0500, Rob Crittenden wrote: > > I finally got around to testing the uid/gid auto-generation thinger. > > > > I commented out the hardcoded uidnumber['501'] and adding a user > > automatically generates a uid. So that's good. > > > > But each user also needs a gidNumber. What should that value be? I don't > > think we've ever come to a resolution on that. > > it depends on whether we want to keep doing the insane thing the OS does > (ie a group for each user by default) in which case we should also > create that group (bleah) an make gid == uid, or use a more saner > default, create a "Users" group and make that be their default primary > group on creation. > I thought that we decided to do the second because adding that many groups causes huge numbers of problems. Karl From kmacmill at redhat.com Tue Nov 13 19:06:13 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 13 Nov 2007 14:06:13 -0500 Subject: [Freeipa-devel] [PATCH] Allow setting of lib directory to correct non-rpm builds on x86_64 In-Reply-To: <4739EFC2.3010401@redhat.com> References: <4739EFC2.3010401@redhat.com> Message-ID: <1194980773.9034.4.camel@clapton.mentalrootkit.com> On Tue, 2007-11-13 at 13:41 -0500, Rob Crittenden wrote: > Karl MacMillan wrote: > > # HG changeset patch > > # User "Karl MacMillan " > > # Date 1194977427 18000 > > # Node ID bf49b683c8d145bf5e757b716791f116c9e81a5e > > # Parent 88eab4025284d2e7053b1ad29b93f498aa199378 > > Allow setting of lib directory to correct non-rpm builds on x86_64. > > > > With this patch you will need to run: > > make autogen LIBDIR=/usr/lib64 > > Also works for 'make all'. > > Ok. Did you want the rpm building to use this method too? > No - rpm detects all of this for us and the spec files call configure directly with the information provided by rpm. Karl From kmacmill at redhat.com Tue Nov 13 19:09:27 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 13 Nov 2007 14:09:27 -0500 Subject: [Freeipa-devel] dna_plugin In-Reply-To: <1194980657.9034.2.camel@clapton.mentalrootkit.com> References: <4739E0C1.6050706@redhat.com> <1194978524.4104.39.camel@localhost.localdomain> <1194980657.9034.2.camel@clapton.mentalrootkit.com> Message-ID: <1194980967.9034.6.camel@clapton.mentalrootkit.com> On Tue, 2007-11-13 at 14:04 -0500, Karl MacMillan wrote: > On Tue, 2007-11-13 at 13:28 -0500, Simo Sorce wrote: > > On Tue, 2007-11-13 at 12:37 -0500, Rob Crittenden wrote: > > > I finally got around to testing the uid/gid auto-generation thinger. > > > > > > I commented out the hardcoded uidnumber['501'] and adding a user > > > automatically generates a uid. So that's good. > > > > > > But each user also needs a gidNumber. What should that value be? I don't > > > think we've ever come to a resolution on that. > > > > it depends on whether we want to keep doing the insane thing the OS does > > (ie a group for each user by default) in which case we should also > > create that group (bleah) an make gid == uid, or use a more saner > > default, create a "Users" group and make that be their default primary > > group on creation. > > > > I thought that we decided to do the second because adding that many > groups causes huge numbers of problems. > And then we probably then want to make the default group added to users configurable. Karl From prowley at redhat.com Tue Nov 13 19:31:01 2007 From: prowley at redhat.com (Pete Rowley) Date: Tue, 13 Nov 2007 11:31:01 -0800 Subject: [Freeipa-devel] [PATCH] post install memberof task In-Reply-To: <1194977227.9034.0.camel@clapton.mentalrootkit.com> References: <472FB5CF.6060103@redhat.com> <4731D134.8010904@redhat.com> <47321CB2.7020205@redhat.com> <47321E2C.2000704@redhat.com> <1194622535.3246.29.camel@clapton.mentalrootkit.com> <4734B553.508@redhat.com> <1194977227.9034.0.camel@clapton.mentalrootkit.com> Message-ID: <4739FB75.801@redhat.com> Karl MacMillan wrote: > On Fri, 2007-11-09 at 11:30 -0800, Pete Rowley wrote: > >> Karl MacMillan wrote: >> >>>> I didn't try it but our call to ldapmodify doesn't include -a and the >>>> ldif doesn't have a changetype, so I assumed it would crap out. >>>> >>>> >>> Pete - any resolution on this? Should I import the patch or not? >>> >>> >> It worked ok when I tested it so lets import. >> >> > > Doesn't work for me - I get: > > [14/11]: initializing group membership > root : CRITICAL Failed to load memberof-conf.ldif: Command > '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w box > -f /tmp/tmp_sqh6R' returned non-zero exit status 32 > Does the behavior change when you insert changetype: add? -- Pete -------------- 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 kmacmill at redhat.com Tue Nov 13 19:37:42 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 13 Nov 2007 14:37:42 -0500 Subject: [Freeipa-devel] [PATCH] Multi-valued field support In-Reply-To: <4733D0BE.9030008@redhat.com> References: <4733D0BE.9030008@redhat.com> Message-ID: <1194982662.3760.0.camel@clapton.mentalrootkit.com> On Thu, 2007-11-08 at 22:15 -0500, Rob Crittenden wrote: > This patch enables multi-value field support for some attributes on the > edit pages (not the new pages). I punted on new because multiple values > on the cn makes doing auto-suggest trickier. I'll come back to it. > > I improved error reporting in the GUI by printing the LDAP message as well. > > I also wrote up a short document describing how multi-valued fields work > (so I don't forget later). > Pushed. > Also attached is a required SRPM of the new widget. This RPM just > re-packages an already packaged file. TG uses "egg" format for > distributing stuff (zip file basically). My RPM just moves data around. > I'll put this up on freeipa.org soon. Karl From rcritten at redhat.com Tue Nov 13 20:03:53 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 13 Nov 2007 15:03:53 -0500 Subject: [Freeipa-devel] [PATCH] let uid/gid be automatically assigned Message-ID: <473A0329.6000706@redhat.com> Use the dna plugin to automatically assign uid and gid Set gid to the group "ipausers" Add the user to this default group rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-374-uid.patch Type: text/x-patch Size: 2531 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 Nov 13 20:09:42 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 13 Nov 2007 15:09:42 -0500 Subject: [Freeipa-devel] Re: things to be stored In-Reply-To: <472B47C7.8030106@redhat.com> References: <472B47C7.8030106@redhat.com> Message-ID: <473A0486.2040206@redhat.com> Rob Crittenden wrote: > I could care less how the configuration is stored in LDAP, either as a > extensibleObject or with its own schema, but here is the stuff I need > stored somewhere: > > userSearchFields, a list of attributes e.g. > uid,givenName,sn,telephoneNumber,ou,title > > searchTimeLimit, an integer, e.g. 2 > > customFields, a set of tuple of the form (label, attribute, required). > All are strings. required is a boolean but will contain "true" or > "false". This needs to be extensible as at some point we'll add a > validator as well, and who knows what else, maybe things to limit field > length, min/max size, etc. > > The current hardcoded version, in python, looks like: > > schema = [ > { 'label': 'See Also', > 'field': 'seeAlso', > 'required': 'true', } , > { 'label': 'O O O', > 'field': 'o', > 'required': 'false', } , > ] > > Another thing we need to think about is how I'll fetch this from the > server. Currently all requests to the server need to be authenticated > but it would probably be better performance-wise to grab this at startup > time. So should we allow unauthenticated requests to the XML-RPC > interface? Currently the whole thing requires SSL and kerberos. Found some more things to store: - root of home directory (e.g. /home, /u, /export1/home, whatever) - default shell (going with /bin/bash by default) - default group that new users are automatically added to (ipausers by default) 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 Nov 13 20:39:14 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 13 Nov 2007 15:39:14 -0500 Subject: [Freeipa-devel] [PATCH] more policy fields Message-ID: <473A0B72.5010108@redhat.com> Added some more fields to the IPA Policy page. It still lacks a storage backend. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-375-morepolicy.patch Type: text/x-patch Size: 6604 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 Nov 13 20:49:27 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 13 Nov 2007 15:49:27 -0500 Subject: [Freeipa-devel] [PATCH] Don't require e-mail addr in the UI Message-ID: <473A0DD7.8010801@redhat.com> Remove the requirement for a non-empty e-mail address in the UI. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-376-noemail.patch Type: text/x-patch Size: 872 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 adingman at redhat.com Tue Nov 13 21:24:16 2007 From: adingman at redhat.com (Andrew C. Dingman) Date: Tue, 13 Nov 2007 16:24:16 -0500 Subject: [Fwd: Re: [Freeipa-devel] dna_plugin] Message-ID: <1194989056.11243.25.camel@sinope.internal.dingman.org> Meant to send all this to the list the first time. Simo's right, but I find contradicting smart people is good for my thought process :) -------- Forwarded Message -------- > From: Simo Sorce > To: Andrew C. Dingman > Subject: Re: [Freeipa-devel] dna_plugin > Date: Tue, 13 Nov 2007 16:13:42 -0500 > > On Tue, 2007-11-13 at 16:06 -0500, Andrew C. Dingman wrote: > > Hmm. Meant to send that to the list. Oops. > > Feel free to forward with my answer if you want. > > > On Tue, 2007-11-13 at 15:47 -0500, Simo Sorce wrote: > > > On Tue, 2007-11-13 at 14:10 -0500, Andrew C. Dingman wrote: > > > > > > > > There is actually a defensible reason for the user private group > > > > thing. > > > > Basically, on shared machines, you have two conflicting desires. On > > > > the > > > > one hand, you want to have each user's private files automatically > > > > created only accessible by the user, eg, umask of 077 or similar. On > > > > the > > > > other, you'd like work in shared directories to automatically be > > > > accessible by all the folks who have access to the shared directory, > > > > eg, > > > > umask of 007. Sure, one *can* change one's umask, but users don't know > > > > that, and most of them wouldn't want to be bothered with it if they > > > > did. > > > > > > Yes this was *the* hack, but this *was* defensible 10 years ago when we > > > didn't have Posix ACLs. > > > I can't find it defensible anymore today, we can do much better. > > > > > > > By using UPGs as the users' primary groups, they can all use a umask > > > > of > > > > 007 and still expect that a new file created in /tmp or ~ will only be > > > > readable by whoever created it, because the owning group is the > > > > single-member primary group. However, as long as collaborative > > > > directories are owned by the right group and have the SGID bit set, > > > > new > > > > files in those directories will be created owned by the appropriate > > > > normal group, and therefore allow the other group members to work with > > > > them. > > > > > > The solution is Posix ACLs and means to easily manipulate them (we have > > > a plugin for nautilus that is not bad, need only some more work to make > > > easy to set things recursively). > > > > AFAICS, the only defense now is that people still use file systems that > > don't have ACL support for some things. I think by now it's pretty much > > down to non-Linux platforms and legacy systems, but it's still out > > there. Last I checked, for example, ACLs wouldn't work on an NFS share > > used by both Mac and Linux clients, 'cause OS X didn't have ACL support. > > However, I'd have to agree that "setfacl -m > > d:g:groupname:rw /shared/dir" is the more elegant solution any place it > > works. > > Yes but these systems are a minority today. FreeIPA wants to be a modern > Identity Management system and we would like to see bad practices go > away. > If the customers need nothing will prevent them from creating a group > for each user, but I don't want this to be the default, it should never > have been. > > Simo. > -- Andrew C. Dingman, RHCX, RHCSS, RHCDS, RHCE Instructor, Red Hat Global Learning Services adingman at redhat.com gpg: 4DEB 3DF1 1007 B26D EC76 80F4 3C26 A4EB 2975 74B2 -------------- 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 kmacmill at redhat.com Tue Nov 13 21:53:38 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 13 Nov 2007 16:53:38 -0500 Subject: [Freeipa-devel] [PATCH] redirect web requests to FQDN In-Reply-To: <4738AE47.4090501@redhat.com> References: <4738AE47.4090501@redhat.com> Message-ID: <1194990818.3578.2.camel@clapton.mentalrootkit.com> On Mon, 2007-11-12 at 14:49 -0500, Rob Crittenden wrote: > Redirect browser request to the FQDN of the server to avoid kerberos > hostname issues. > Pushed. From kmacmill at redhat.com Tue Nov 13 21:54:04 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 13 Nov 2007 16:54:04 -0500 Subject: [Freeipa-devel] [PATCH] underline sortable columns In-Reply-To: <4738B465.6090802@redhat.com> References: <4738B465.6090802@redhat.com> Message-ID: <1194990844.3578.4.camel@clapton.mentalrootkit.com> On Mon, 2007-11-12 at 15:15 -0500, Rob Crittenden wrote: > Sort columns will be underlined so the fact that they are sortable is > more obvious. > > Restoring the up/down arrows to indicate sort order. > Pushed. From kmacmill at redhat.com Tue Nov 13 21:55:29 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 13 Nov 2007 16:55:29 -0500 Subject: [Freeipa-devel] [PATCH] require unique delegations In-Reply-To: <4734AE17.9090007@redhat.com> References: <4734AE17.9090007@redhat.com> Message-ID: <1194990929.3578.6.camel@clapton.mentalrootkit.com> On Fri, 2007-11-09 at 13:59 -0500, Rob Crittenden wrote: > Require uniqueness in the name/comment field of delegations > Fix error reporting in the UI to include the detailed message > Sort delegations by name when displaying them > Update the name field from "Name" to "Delegation Name" as suggested by > David O'Brien > I pushed this, but honestly, I still don't like this named delegation thing. Why not just use the source and target group as a key and display based on that? Karl From kmacmill at redhat.com Tue Nov 13 21:56:02 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 13 Nov 2007 16:56:02 -0500 Subject: [Freeipa-devel] [PATCH] some minor group fixes In-Reply-To: <4734AEAD.9040000@redhat.com> References: <4734AEAD.9040000@redhat.com> Message-ID: <1194990962.3578.8.camel@clapton.mentalrootkit.com> On Fri, 2007-11-09 at 14:02 -0500, Rob Crittenden wrote: > This patch likely depends on the multi-value patch. > > Fixes an error when editing a group with a single-valued cn field. > > Some error messages were displaying e.detail instead of just the desc > portion of that (so it was super ugly) > Pushed. From kmacmill at redhat.com Tue Nov 13 21:56:53 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 13 Nov 2007 16:56:53 -0500 Subject: [Freeipa-devel] [PATCH] Handle no credentials cache more gracefully In-Reply-To: <4734BB8D.4030401@redhat.com> References: <4734BB8D.4030401@redhat.com> Message-ID: <1194991013.3578.10.camel@clapton.mentalrootkit.com> On Fri, 2007-11-09 at 14:57 -0500, Rob Crittenden wrote: > Don't continue if a kerberos credentials cache is not available. This > used to throw a really cryptic error because it was getting into the > very old proxy code. > > Apache forked-model detection was incorrect. > > Both of these return an error instead of raising one (so the user gets > feedback instead of a 500 error). > Pushed - we likely need a lot more of this type of patch so that our errors are understandable. Karl From kmacmill at redhat.com Tue Nov 13 21:59:05 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 13 Nov 2007 16:59:05 -0500 Subject: [Freeipa-devel] [PATCH] delete users on command-line In-Reply-To: <4734C71F.20003@redhat.com> References: <4734C71F.20003@redhat.com> Message-ID: <1194991145.3578.13.camel@clapton.mentalrootkit.com> On Fri, 2007-11-09 at 15:46 -0500, Rob Crittenden wrote: > Add the capability to completely delete a user from the database. The > default remains to inactivate them. > > The UI already has the ability to delete users (as well as inactivate). > > I did a minor bit of testing to test referential integrity and in my > little tests things worked as they should. Pushed. I'm concerned that the default doesn't match system userdel. Perhaps we should create ipa-userinactive instead? Karl From kmacmill at redhat.com Tue Nov 13 21:59:55 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 13 Nov 2007 16:59:55 -0500 Subject: [Freeipa-devel] [PATCH] handle ldap.UNWILLING_TO_PERFORM In-Reply-To: <4734D28C.1090400@redhat.com> References: <4734D28C.1090400@redhat.com> Message-ID: <1194991195.3578.15.camel@clapton.mentalrootkit.com> On Fri, 2007-11-09 at 16:35 -0500, Rob Crittenden wrote: > Handle ldap.UNWILLING_TO_PERFORM more gracefully. > > This is seen if you have an inactivated account and you try to do something. Pushed. From kmacmill at redhat.com Tue Nov 13 22:02:35 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 13 Nov 2007 17:02:35 -0500 Subject: [Freeipa-devel] [PATCH] part one of allowing RDN changes In-Reply-To: <47392455.4040405@redhat.com> References: <47392455.4040405@redhat.com> Message-ID: <1194991355.3578.18.camel@clapton.mentalrootkit.com> On Mon, 2007-11-12 at 23:13 -0500, Rob Crittenden wrote: > - Allow a user or group to change an attribute in its RDN > - Add secretary to the list of indexes otherwise RDN changing could be slow > - Port --addattr, --setattr and --delattr from usermod to groupmod > > One can do it via the command line with something like: > > % ipa-usermod --setattr=uid=joesomebody joenobody > Pushed without proxyprovider.py debugging changes. > Doing this in the UI will take a bit more time and thought. I'm not sure > I want it to be very easy to do this. I know I've hated my login at > several companies I've worked for but have been told (it's our policy). > So we should tread carefully. > > I'm thinking that this field may only be editable if you're in the > admins group (in the UI only). > The creeping hack :) I think that's OK - in v2 we are going to have to resolve these sorts of policy issues more cleanly. Karl From kmacmill at redhat.com Tue Nov 13 22:06:08 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 13 Nov 2007 17:06:08 -0500 Subject: [Freeipa-devel] [PATCH] Restrict access to parts of the UI In-Reply-To: <4739CDAB.5070809@redhat.com> References: <4739CDAB.5070809@redhat.com> Message-ID: <1194991568.3578.20.camel@clapton.mentalrootkit.com> On Tue, 2007-11-13 at 11:15 -0500, Rob Crittenden wrote: > Restrict access to some parts of the UI to those in the admins group. Pushed. That identity.require trick is pretty nice. Karl From kmacmill at redhat.com Tue Nov 13 22:07:57 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 13 Nov 2007 17:07:57 -0500 Subject: [Freeipa-devel] [PATCH] Allow setting of lib directory to correct non-rpm builds on x86_64 In-Reply-To: References: Message-ID: <1194991677.3578.22.camel@clapton.mentalrootkit.com> On Tue, 2007-11-13 at 13:10 -0500, Karl MacMillan wrote: > # HG changeset patch > # User "Karl MacMillan " > # Date 1194977427 18000 > # Node ID bf49b683c8d145bf5e757b716791f116c9e81a5e > # Parent 88eab4025284d2e7053b1ad29b93f498aa199378 > Allow setting of lib directory to correct non-rpm builds on x86_64. > > With this patch you will need to run: > make autogen LIBDIR=/usr/lib64 > Also works for 'make all'. > Pushed. From kmacmill at redhat.com Tue Nov 13 22:08:34 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 13 Nov 2007 17:08:34 -0500 Subject: [Freeipa-devel] [PATCH] Don't require e-mail addr in the UI In-Reply-To: <473A0DD7.8010801@redhat.com> References: <473A0DD7.8010801@redhat.com> Message-ID: <1194991714.3578.24.camel@clapton.mentalrootkit.com> On Tue, 2007-11-13 at 15:49 -0500, Rob Crittenden wrote: > Remove the requirement for a non-empty e-mail address in the UI. > Pushed. From kmacmill at redhat.com Tue Nov 13 22:09:03 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 13 Nov 2007 17:09:03 -0500 Subject: [Freeipa-devel] [PATCH] let uid/gid be automatically assigned In-Reply-To: <473A0329.6000706@redhat.com> References: <473A0329.6000706@redhat.com> Message-ID: <1194991743.3578.26.camel@clapton.mentalrootkit.com> On Tue, 2007-11-13 at 15:03 -0500, Rob Crittenden wrote: > Use the dna plugin to automatically assign uid and gid > Set gid to the group "ipausers" > Add the user to this default group > Pushed. From ssorce at redhat.com Tue Nov 13 22:10:18 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 13 Nov 2007 17:10:18 -0500 Subject: [Freeipa-devel] [PATCH] Password Policy suppord in ipa_pwd_extop Message-ID: <1194991818.1885.1.camel@hopeson> The patch includes all checks except password history Will ad that with a later patch. Simo. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-368-password-policy.patch Type: text/x-patch Size: 28401 bytes Desc: not available URL: From rcritten at redhat.com Tue Nov 13 22:24:31 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 13 Nov 2007 17:24:31 -0500 Subject: [Freeipa-devel] [PATCH] fix broken build Message-ID: <473A241F.30009@redhat.com> My policy patch had some non-existent files referenced in Makefile.am which broke the build. This should fix that. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-380-broken.patch Type: text/x-patch Size: 1059 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 kmacmill at redhat.com Tue Nov 13 22:27:09 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 13 Nov 2007 17:27:09 -0500 Subject: [Freeipa-devel] [PATCH] fix broken build In-Reply-To: <473A241F.30009@redhat.com> References: <473A241F.30009@redhat.com> Message-ID: <1194992829.3578.28.camel@clapton.mentalrootkit.com> On Tue, 2007-11-13 at 17:24 -0500, Rob Crittenden wrote: > My policy patch had some non-existent files referenced in Makefile.am > which broke the build. This should fix that. > Pushed. From kmacmill at redhat.com Tue Nov 13 22:27:45 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 13 Nov 2007 17:27:45 -0500 Subject: [Freeipa-devel] [PATCH] Initial policy support In-Reply-To: <4738A881.3000309@redhat.com> References: <4738A881.3000309@redhat.com> Message-ID: <1194992865.3578.30.camel@clapton.mentalrootkit.com> On Mon, 2007-11-12 at 14:24 -0500, Rob Crittenden wrote: > Here is the shell of support for policy editing. While not really a > pluggable architecture there is a main "Policy" page that will let one > pick from a variety of choices (currently just IPA Policy). > > At some point we could populate this list from LDAP such it will be much > easier to insert new forms (but it may still require some editing of > files to have them loaded, I'm not sure yet). > Pushed. From kmacmill at redhat.com Tue Nov 13 22:28:13 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 13 Nov 2007 17:28:13 -0500 Subject: [Freeipa-devel] [PATCH] more policy fields In-Reply-To: <473A0B72.5010108@redhat.com> References: <473A0B72.5010108@redhat.com> Message-ID: <1194992893.3578.32.camel@clapton.mentalrootkit.com> On Tue, 2007-11-13 at 15:39 -0500, Rob Crittenden wrote: > Added some more fields to the IPA Policy page. It still lacks a storage > backend. > Pushed. From rcritten at redhat.com Tue Nov 13 22:52:43 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 13 Nov 2007 17:52:43 -0500 Subject: [Freeipa-devel] [PATCH] fix FQDN error during install Message-ID: <473A2ABB.5030505@redhat.com> I forgot to include FQDN in the substition list in httpinstance.py so ipa-server-install would fail. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-381-httpfqdn.patch Type: text/x-patch Size: 782 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 david.obrien at redhat.com Wed Nov 14 02:58:24 2007 From: david.obrien at redhat.com (David O'Brien) Date: Wed, 14 Nov 2007 12:58:24 +1000 Subject: [Freeipa-devel] http vs https for connecting to ipa server In-Reply-To: <4739B3EC.1020202@redhat.com> References: <47391D65.4040606@redhat.com> <47391DE3.3030501@redhat.com> <47391EFA.4000103@redhat.com> <4739B3EC.1020202@redhat.com> Message-ID: <473A6450.8010700@redhat.com> Rob Crittenden wrote: > David O'Brien wrote: >> Rob Crittenden wrote: >>> David O'Brien wrote: >>>> I thought this worked before... >>>> >>>> When I wanted to connect to the server from the client, I just used >>>> http://fqdn and it auto switched to https:// >>>> >>>> Today I have to explicitly use https or I get a "can't connect to >>>> server" message. >>>> >>>> I'm logged in to the client as a non-admin user, got a ticket ok, etc. >>>> >>>> Running on 32bit F7 >>>> >>>> >>> Can you post /etc/httpd/conf.d/ipa.conf? >>> >>> rob >> here you go >> >> > > Wierd. It has the port forwarding there. Have you tried restarting Apache? > > What does Apache log when you get the "can't connect" error? What client > are you using? > > rob I forgot to retry this this morning. I'm in the middle of installing a later server and client, etc. I'll see what happens then. atm I'm running everything on F7 32 bit. Server and client on different VMs. -- David O'Brien RHCT PGP-KeyID: 0x443CBA7B -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From rcritten at redhat.com Wed Nov 14 04:21:58 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 13 Nov 2007 23:21:58 -0500 Subject: [Freeipa-devel] new TGExpandingFormWidget Message-ID: <473A77E6.3050401@redhat.com> Using another Fedora Python rpm as a template I've created a new version of TGExpandingFormWidget that works better (and it should be easier to incorporate into Fedora as a result). http://rcritten.fedorapeople.org/python-tgexpandingformwidget-0.1.3-2.fc7.noarch.rpm http://rcritten.fedorapeople.org/python-tgexpandingformwidget-0.1.3-2.fc7.src.rpm 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 david.obrien at redhat.com Wed Nov 14 05:08:33 2007 From: david.obrien at redhat.com (David O'Brien) Date: Wed, 14 Nov 2007 15:08:33 +1000 Subject: [Freeipa-devel] [PATCH] delete users on command-line In-Reply-To: <1194991145.3578.13.camel@clapton.mentalrootkit.com> References: <4734C71F.20003@redhat.com> <1194991145.3578.13.camel@clapton.mentalrootkit.com> Message-ID: <473A82D1.204@redhat.com> Karl MacMillan wrote: > On Fri, 2007-11-09 at 15:46 -0500, Rob Crittenden wrote: >> Add the capability to completely delete a user from the database. The >> default remains to inactivate them. >> >> The UI already has the ability to delete users (as well as inactivate). >> >> I did a minor bit of testing to test referential integrity and in my >> little tests things worked as they should. > > Pushed. I'm concerned that the default doesn't match system userdel. > Perhaps we should create ipa-userinactive instead? > > Karl or perhaps we could create ipa-inactivateuser in keeping with the (almost) ubiquitous "ipa-" syntax of the existing IPA commands. System commands are another matter; they're all the other way around, which is probably a good thing. Actually "inactivate" grates on my ears, but it's a valid word so I can't really complain. I would have gone "deactivate" myself, even though the result is an "inactive" object. You gotta love English... -- David O'Brien RHCT PGP-KeyID: 0x443CBA7B -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From rcritten at redhat.com Wed Nov 14 14:16:41 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Nov 2007 09:16:41 -0500 Subject: [Freeipa-devel] [PATCH] require unique delegations In-Reply-To: <1194990929.3578.6.camel@clapton.mentalrootkit.com> References: <4734AE17.9090007@redhat.com> <1194990929.3578.6.camel@clapton.mentalrootkit.com> Message-ID: <473B0349.2090607@redhat.com> Karl MacMillan wrote: > On Fri, 2007-11-09 at 13:59 -0500, Rob Crittenden wrote: >> Require uniqueness in the name/comment field of delegations >> Fix error reporting in the UI to include the detailed message >> Sort delegations by name when displaying them >> Update the name field from "Name" to "Delegation Name" as suggested by >> David O'Brien >> > > I pushed this, but honestly, I still don't like this named delegation > thing. Why not just use the source and target group as a key and display > based on that? > > Karl > Well, that could reduce the overall number of aci's (because left hand doesn't know that right hand has already created a similar aci). It would have to handle someone trying to create a new aci for the same source/target and redirect the user appropriately. I won't have time to address this before Friday but if you want to open a ticket we can discuss this further. 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 Nov 14 14:20:54 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Nov 2007 09:20:54 -0500 Subject: [Freeipa-devel] [PATCH] delete users on command-line In-Reply-To: <1194991145.3578.13.camel@clapton.mentalrootkit.com> References: <4734C71F.20003@redhat.com> <1194991145.3578.13.camel@clapton.mentalrootkit.com> Message-ID: <473B0446.5050800@redhat.com> Karl MacMillan wrote: > On Fri, 2007-11-09 at 15:46 -0500, Rob Crittenden wrote: >> Add the capability to completely delete a user from the database. The >> default remains to inactivate them. >> >> The UI already has the ability to delete users (as well as inactivate). >> >> I did a minor bit of testing to test referential integrity and in my >> little tests things worked as they should. > > Pushed. I'm concerned that the default doesn't match system userdel. > Perhaps we should create ipa-userinactive instead? > > Karl > Well, we can always reverse that, so that it deletes unless you request inactivation. The thing is that inactivation is reversable, deletion is not. 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 kmacmill at redhat.com Wed Nov 14 15:07:09 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Wed, 14 Nov 2007 10:07:09 -0500 Subject: [Freeipa-devel] new TGExpandingFormWidget In-Reply-To: <473A77E6.3050401@redhat.com> References: <473A77E6.3050401@redhat.com> Message-ID: <1195052829.21623.14.camel@clapton.mentalrootkit.com> On Tue, 2007-11-13 at 23:21 -0500, Rob Crittenden wrote: > Using another Fedora Python rpm as a template I've created a new version > of TGExpandingFormWidget that works better (and it should be easier to > incorporate into Fedora as a result). > > http://rcritten.fedorapeople.org/python-tgexpandingformwidget-0.1.3-2.fc7.noarch.rpm > http://rcritten.fedorapeople.org/python-tgexpandingformwidget-0.1.3-2.fc7.src.rpm > Thanks - this makes everything work for me. I put these up on freeipa.org for download and in the F-7 repos. Karl From rcritten at redhat.com Wed Nov 14 15:12:28 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Nov 2007 10:12:28 -0500 Subject: [Freeipa-devel] new TGExpandingFormWidget In-Reply-To: <1195052829.21623.14.camel@clapton.mentalrootkit.com> References: <473A77E6.3050401@redhat.com> <1195052829.21623.14.camel@clapton.mentalrootkit.com> Message-ID: <473B105C.9070406@redhat.com> Karl MacMillan wrote: > On Tue, 2007-11-13 at 23:21 -0500, Rob Crittenden wrote: >> Using another Fedora Python rpm as a template I've created a new version >> of TGExpandingFormWidget that works better (and it should be easier to >> incorporate into Fedora as a result). >> >> http://rcritten.fedorapeople.org/python-tgexpandingformwidget-0.1.3-2.fc7.noarch.rpm >> http://rcritten.fedorapeople.org/python-tgexpandingformwidget-0.1.3-2.fc7.src.rpm >> > > Thanks - this makes everything work for me. I put these up on > freeipa.org for download and in the F-7 repos. > > Karl > We still need a dependency in the spec file so it gets pulled automatically, I forgot to add that. 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 Nov 14 15:51:24 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Nov 2007 10:51:24 -0500 Subject: [Freeipa-devel] [PATCH] finish up access control Message-ID: <473B197C.9070800@redhat.com> Add an editors group. This is used to generally grant access for users to edit other users (the Edit link won't appear otherwise). Additional delegation is need to grant permission to individual attributes. Update the failed login page to indicate that it is a permission issue. Don't allow access to policy at all for non-admins. By default users can only edit themselves. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-383-access.patch Type: text/x-patch Size: 13049 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 Nov 14 16:40:37 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Nov 2007 11:40:37 -0500 Subject: [Freeipa-devel] multi-valued cn in groups and memberOf? Message-ID: <473B2505.4040508@redhat.com> Pete. If we have a group with a multi-valued CN how does memberOf deal with that? Does it create a separate memberOf for each one? Or does it use only the "first" CN, whatever that means? So if I have cn=doctors,cn=quacks,cn=groups,... And a member: uid=spock,cn=accounts,... If I do a memberOf what will I get back? That spock is a member of doctors, or quacks or both? This has implications on doing RDN changes. If we drop a CN I need to know what to expect when it comes to group membership. The uniquemembers field will be the same, of course, but what about memberOf? thanks 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 jdennis at redhat.com Wed Nov 14 18:31:39 2007 From: jdennis at redhat.com (John Dennis) Date: Wed, 14 Nov 2007 13:31:39 -0500 Subject: [Freeipa-devel] radius status as of 11/14 Message-ID: <473B3F0B.6090202@redhat.com> In the past week: The freeradius ldap module was modified: * To read the client (e.g. NAS device) list from LDAP instead of from a flat file, postprocess the client info, and merge into the existing client list. * Diagnosed and fixed a bug in the LDAP TLS code which prevented unsigned certificates from being accepted. The radius support in IPA wes augmented: * The LDAP schema was extended for radius clients * The bootstrapping of the initial LDAP tree structure was extended to include radius service data (i.e. client list, user profile list) * Initialization code was added to the ipa server install so the directory server would encrypt the NAS secret it stores so it can't be read in the directory server database file. * The directory server configuration was extended to set ACI's (access controls) on the radius service data such that only the radius service principal and the admin and view and modify radius data. * The ipa installation code for radius was modified to: - perform radius authentication for user's using the user's IPA kerberous ticket - enable client list LDAP lookup's in IPA - turn off authorization decisions based on the presence of an LDAP user attribute - enable profile groups, set a default profile, allow per user profile group indirection in the newly added profile section of ldap * Added support for manipulating radius clients in IPA. - Added new command line utilities: ipa-radiusclient{add, modify, delete, list} - Added the internal data structure in IPA for radius clients - Added new sets of xmlrpc handling code for the radius clients. -- John Dennis From prowley at redhat.com Wed Nov 14 19:00:25 2007 From: prowley at redhat.com (Pete Rowley) Date: Wed, 14 Nov 2007 11:00:25 -0800 Subject: [Freeipa-devel] multi-valued cn in groups and memberOf? In-Reply-To: <473B2505.4040508@redhat.com> References: <473B2505.4040508@redhat.com> Message-ID: <473B45C9.6080408@redhat.com> Rob Crittenden wrote: > Pete. > > If we have a group with a multi-valued CN how does memberOf deal with > that? > > Does it create a separate memberOf for each one? Or does it use only > the "first" CN, whatever that means? > > So if I have cn=doctors,cn=quacks,cn=groups,... > > And a member: uid=spock,cn=accounts,... > > If I do a memberOf what will I get back? That spock is a member of > doctors, or quacks or both? > > This has implications on doing RDN changes. If we drop a CN I need to > know what to expect when it comes to group membership. The > uniquemembers field will be the same, of course, but what about memberOf? memberof uses the dn, it doesn't care about anything else. If you drop a cn that is part of the rdn then a) you have performed a mod dn op, and b) the referential integrity plugin will take care of the change in uniquemember and c) the memberof plugin will take care of it in memberof. -- Pete -------------- 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 rcritten at redhat.com Wed Nov 14 19:03:23 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Nov 2007 14:03:23 -0500 Subject: [Freeipa-devel] [PATCH] make unauthorized page generic Message-ID: <473B467B.8060108@redhat.com> Remove reference to idm wiki and make the unauthorized page generic. It is installed into /usr/share/ipa/html so can be customized as desired by end-users. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-395-errormsg.patch Type: text/x-patch Size: 929 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 Nov 14 20:09:21 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Nov 2007 15:09:21 -0500 Subject: [Freeipa-devel] Changing krbprincipalname Message-ID: <473B55F1.2090807@redhat.com> I'm working on the rdn change and have run into a problem: I can't change the krbprincipalname and still authenticate. If I try to change the krbprincipalname and authenticate with it I get: kinit(v5): Client not found in Kerberos database while getting initial credentials It doesn't make a lot of sense to change the uid but not the principal name. I assume I have to change something else but I've no idea what. 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 Nov 14 20:19:08 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Nov 2007 15:19:08 -0500 Subject: [Freeipa-devel] [PATCH] Password Policy suppord in ipa_pwd_extop In-Reply-To: <1194991818.1885.1.camel@hopeson> References: <1194991818.1885.1.camel@hopeson> Message-ID: <473B583C.5080504@redhat.com> Simo Sorce wrote: > The patch includes all checks except password history > Will ad that with a later patch. > > Simo. Granted I don't know a whole lot about kerberos internals or FDS plugins but these changes seem fine. 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 Nov 14 20:40:36 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Nov 2007 15:40:36 -0500 Subject: [Freeipa-devel] [PATCH] better error message of Apache is down Message-ID: <473B5D44.1010706@redhat.com> If unable to connect to the XML-RPC server print a more useful error msg. I also noticed that some cmd-line tools were missing some error handling. Added that too. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-396-errmsg.patch Type: text/x-patch Size: 8876 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 Nov 14 20:44:26 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Nov 2007 15:44:26 -0500 Subject: [Freeipa-devel] multi-valued cn in groups and memberOf? In-Reply-To: <473B45C9.6080408@redhat.com> References: <473B2505.4040508@redhat.com> <473B45C9.6080408@redhat.com> Message-ID: <473B5E2A.5070007@redhat.com> Pete Rowley wrote: > Rob Crittenden wrote: >> Pete. >> >> If we have a group with a multi-valued CN how does memberOf deal with >> that? >> >> Does it create a separate memberOf for each one? Or does it use only >> the "first" CN, whatever that means? >> >> So if I have cn=doctors,cn=quacks,cn=groups,... >> >> And a member: uid=spock,cn=accounts,... >> >> If I do a memberOf what will I get back? That spock is a member of >> doctors, or quacks or both? >> >> This has implications on doing RDN changes. If we drop a CN I need to >> know what to expect when it comes to group membership. The >> uniquemembers field will be the same, of course, but what about memberOf? > memberof uses the dn, it doesn't care about anything else. If you drop a > cn that is part of the rdn then a) you have performed a mod dn op, and > b) the referential integrity plugin will take care of the change in > uniquemember and c) the memberof plugin will take care of it in memberof. > Hmm. So does this mean we shouldn't allow multi-valued groups then? I can see someone thinking they can use multiple cns as group aliases which won't work. 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 prowley at redhat.com Wed Nov 14 21:09:39 2007 From: prowley at redhat.com (Pete Rowley) Date: Wed, 14 Nov 2007 13:09:39 -0800 Subject: [Freeipa-devel] multi-valued cn in groups and memberOf? In-Reply-To: <473B5E2A.5070007@redhat.com> References: <473B2505.4040508@redhat.com> <473B45C9.6080408@redhat.com> <473B5E2A.5070007@redhat.com> Message-ID: <473B6413.7070208@redhat.com> Rob Crittenden wrote: > Pete Rowley wrote: >> Rob Crittenden wrote: >>> Pete. >>> >>> If we have a group with a multi-valued CN how does memberOf deal >>> with that? >>> >>> Does it create a separate memberOf for each one? Or does it use only >>> the "first" CN, whatever that means? >>> >>> So if I have cn=doctors,cn=quacks,cn=groups,... >>> >>> And a member: uid=spock,cn=accounts,... >>> >>> If I do a memberOf what will I get back? That spock is a member of >>> doctors, or quacks or both? >>> >>> This has implications on doing RDN changes. If we drop a CN I need >>> to know what to expect when it comes to group membership. The >>> uniquemembers field will be the same, of course, but what about >>> memberOf? >> memberof uses the dn, it doesn't care about anything else. If you >> drop a cn that is part of the rdn then a) you have performed a mod dn >> op, and b) the referential integrity plugin will take care of the >> change in uniquemember and c) the memberof plugin will take care of >> it in memberof. >> > > Hmm. So does this mean we shouldn't allow multi-valued groups then? > > I can see someone thinking they can use multiple cns as group aliases > which won't work. Why not? A cn doesn't have to be in the dn for it to be the name (or alias) of the group. What might cause problems is that we implicitly rely upon dn uniqueness to enforce cn uniqueness - multiple cn's breaks that and would require us to enable the attribute uniqueness plugin to enforce uniqueness, which we cannot really do because it fails in an mmr scenario. Single cn is probably better from that point of view, but we can't enforce that in the DS (unless we write some plugin code). I would say, single cn in groups from the ui for now and make a note for the future that we need either a) an enhanced mmr attribute uniqueness plugin, or b) to further constrain the attribute to single value with an enforcement plugin. a) is a lot harder than b) but b) is likely to annoy some people. -- Pete -------------- 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 rcritten at redhat.com Wed Nov 14 22:51:36 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Nov 2007 17:51:36 -0500 Subject: [Freeipa-devel] [PATCH] finish up multi-valued fields Message-ID: <473B7BF8.7080607@redhat.com> This finishes up multi-valued fields support by including multi-value fields on the Add Person page. I am also removing multi-valued cn from groups because that raises too many issues to handle right now and single-cn groups are easy to map to unix groups (and understand). rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-397-multi.patch Type: text/x-patch Size: 23127 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 kmacmill at redhat.com Wed Nov 14 23:20:05 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Wed, 14 Nov 2007 18:20:05 -0500 Subject: [Freeipa-devel] [PATCH] Refactor ipaldap.py Message-ID: # HG changeset patch # User "Karl MacMillan " # Date 1195082402 18000 # Node ID c97541fa3a402c46e588a5a3f260d85a34a4dcbc # Parent 3aa0f2f6d446e9719d4b2a208b5a754b132549cf Refactor ipaldap.py Make it easier to use ipaldap.py to do simply binds, remove the proxy support, and conform to the overall coding style. diff -r 3aa0f2f6d446 -r c97541fa3a40 ipa-server/ipaserver/ipaldap.py --- a/ipa-server/ipaserver/ipaldap.py Tue Nov 13 15:36:52 2007 -0500 +++ b/ipa-server/ipaserver/ipaldap.py Wed Nov 14 18:20:02 2007 -0500 @@ -71,7 +71,7 @@ class Entry: true otherwise""" return self.data != None and len(self.data) > 0 - def hasAttr(self,name): + def has_attr(self,name): """Return True if this entry has an attribute named name, False otherwise""" return self.data and self.data.has_key(name) @@ -83,23 +83,23 @@ class Entry: entry.getValue('cn') This also allows us to return None if an attribute is not found rather than throwing an exception""" - return self.getValue(name) - - def getValues(self,name): + return self.get_value(name) + + def get_values(self,name): """Get the list (array) of values for the attribute named name""" return self.data.get(name) - def getValue(self,name): + def get_value(self,name): """Get the first value for the attribute named name""" return self.data.get(name,[None])[0] - def setValue(self,name,*value): + def set_value(self,name,*value): """Value passed in may be a single value, several values, or a single sequence. For example: - ent.setValue('name', 'value') - ent.setValue('name', 'value1', 'value2', ..., 'valueN') - ent.setValue('name', ['value1', 'value2', ..., 'valueN']) - ent.setValue('name', ('value1', 'value2', ..., 'valueN')) + ent.set_value('name', 'value') + ent.set_value('name', 'value1', 'value2', ..., 'valueN') + ent.set_value('name', ['value1', 'value2', ..., 'valueN']) + ent.set_value('name', ('value1', 'value2', ..., 'valueN')) Since *value is a tuple, we may have to extract a list or tuple from that tuple as in the last two examples above""" if isinstance(value[0],list) or isinstance(value[0],tuple): @@ -107,9 +107,9 @@ class Entry: else: self.data[name] = value - setValues = setValue - - def toTupleList(self): + set_values = set_value + + def to_tuple_list(self): """Convert the attrs and values to a list of 2-tuples. The first element of the tuple is the attribute name. The second element is either a single value or a list of values.""" @@ -139,11 +139,11 @@ class Entry: def wrapper(f,name): """This is the method that wraps all of the methods of the superclass. This seems - to need to be an unbound method, that's why it's outside of IPAdmin. Perhaps there + to need to be an unbound method, that's why it's outside of LdapObject. Perhaps there is some way to do this with the new classmethod or staticmethod of 2.4. Basically, we replace every call to a method in SimpleLDAPObject (the superclass - of IPAdmin) with a call to inner. The f argument to wrapper is the bound method - of IPAdmin (which is inherited from the superclass). Bound means that it will implicitly + of LdapObject) with a call to inner. The f argument to wrapper is the bound method + of LdapObject (which is inherited from the superclass). Bound means that it will implicitly be called with the self argument, it is not in the args list. name is the name of the method to call. If name is a method that returns entry objects (e.g. result), we wrap the data returned by an Entry class. If name is a method that takes an entry @@ -169,122 +169,75 @@ def wrapper(f,name): # python-ldap ent = args[0] if isinstance(ent,Entry): - return f(ent.dn, ent.toTupleList(), *args[2:]) + return f(ent.dn, ent.to_tuple_list(), *args[2:]) else: return f(*args, **kargs) else: return f(*args, **kargs) return inner -class IPAdmin(SimpleLDAPObject): +class LdapObject(SimpleLDAPObject): CFGSUFFIX = "o=NetscapeRoot" DEFAULT_USER_ID = "nobody" - def __initPart2(self): - if self.binddn and len(self.binddn) and not hasattr(self,'sroot'): - try: - ent = self.getEntry('cn=config', ldap.SCOPE_BASE, '(objectclass=*)', - [ 'nsslapd-instancedir', 'nsslapd-errorlog' ]) - instdir = ent.getValue('nsslapd-instancedir') - self.sroot, self.inst = re.match(r'(.*)[\/]slapd-(\w+)$', instdir).groups() - self.errlog = ent.getValue('nsslapd-errorlog') - except (ldap.INSUFFICIENT_ACCESS, ldap.CONNECT_ERROR, - ipaerror.exception_for(ipaerror.LDAP_NOT_FOUND)): - pass # usually means -# print "ignored exception" - except ldap.LDAPError, e: - print "caught exception ", e - raise ipaerror.gen_exception(ipaerror.LDAP_DATABASE_ERROR, None, e) - - def __localinit__(self): - """If a CA certificate is provided then it is assumed that we are - doing SSL client authentication with proxy auth. - - If a CA certificate is not present then it is assumed that we are - using a forwarded kerberos ticket for SASL auth. SASL provides - its own encryption. - """ - if self.cacert is not None: - SimpleLDAPObject.__init__(self,'ldaps://%s:%d' % (self.host,self.port)) - else: - SimpleLDAPObject.__init__(self,'ldap://%s:%d' % (self.host,self.port)) - - def __init__(self,host,port,cacert,bindcert,bindkey,proxydn=None,debug=None): + def __init__(self, host, port=389, ssl=False, debug=None): """We just set our instance variables and wrap the methods - the real work is done in __localinit__ and __initPart2 - these are separated out this way so that we can call them from places other than instance creation e.g. when we just need to reconnect, not create a new instance""" + + self.port = port + self.host = host + + if ssl: + SimpleLDAPObject.__init__(self,'ldaps://%s:%d' % (self.host,self.port)) + else: + SimpleLDAPObject.__init__(self,'ldap://%s:%d' % (self.host,self.port)) + + if debug and debug.lower() == "on": ldap.set_option(ldap.OPT_DEBUG_LEVEL,255) - if cacert is not None: - ldap.set_option(ldap.OPT_X_TLS_CACERTFILE,cacert) - ldap.set_option(ldap.OPT_X_TLS_CERTFILE,bindcert) - ldap.set_option(ldap.OPT_X_TLS_KEYFILE,bindkey) self.__wrapmethods() - self.port = port or 389 - self.host = host - self.cacert = cacert - self.bindcert = bindcert - self.bindkey = bindkey - self.proxydn = proxydn + + # SSL options - these should be set with set_ssl + self.cacert = None + self.bindcert = None + self.bindkey = None + # see if is local or not - host1 = IPAdmin.getfqdn(host) - host2 = IPAdmin.getfqdn() + host1 = LdapObject.getfqdn(host) + host2 = LdapObject.getfqdn() self.isLocal = (host1 == host2) self.suffixes = {} - self.__localinit__() + + def set_ssl(self, cacert, bindcert, bindkey): + ldap.set_option(ldap.OPT_X_TLS_CACERTFILE,cacert) + ldap.set_option(ldap.OPT_X_TLS_CERTFILE,bindcert) + ldap.set_option(ldap.OPT_X_TLS_KEYFILE,bindkey) + def __str__(self): return self.host + ":" + str(self.port) - def __get_server_controls__(self): - """Create the proxy user server control. The control has the form - 0x04 = Octet String - 4|0x80 sets the length of the string length field at 4 bytes - the struct() gets us the length in bytes of string self.proxydn - self.proxydn is the proxy dn to send""" - - import sys - - if self.proxydn is not None: - proxydn = chr(0x04) + chr(4|0x80) + struct.pack('l', socket.htonl(len(self.proxydn))) + self.proxydn; - - # Create the proxy control - sctrl=[] - sctrl.append(LDAPControl('2.16.840.1.113730.3.4.18',True,proxydn)) - else: - sctrl=None - - return sctrl - - def toLDAPURL(self): + def to_ldap_url(self): return "ldap://%s:%d/" % (self.host,self.port) - def set_proxydn(self, proxydn): - self.proxydn = proxydn - - def set_krbccache(self, krbccache, principal): + + def krb_bind(self, krbccache, principal): if krbccache is not None: os.environ["KRB5CCNAME"] = krbccache self.sasl_interactive_bind_s("", sasl_auth) self.principal = principal - self.proxydn = None - - def getEntry(self,*args): + + def get_entry(self,*args): """This wraps the search function. It is common to just get one entry""" - - sctrl = self.__get_server_controls__() - - if sctrl is not None: - self.set_option(ldap.OPT_SERVER_CONTROLS, sctrl) try: res = self.search(*args) type, obj = self.result(res) - # res = self.search_ext(args[0], args[1], filterstr=args[2], attrlist=args[3], serverctrls=sctrl) except ldap.LDAPError, e: raise ipaerror.gen_exception(ipaerror.LDAP_DATABASE_ERROR, None, e) @@ -296,12 +249,8 @@ class IPAdmin(SimpleLDAPObject): else: # assume list/tuple return obj[0] - def getList(self,*args): + def get_list(self,*args): """This wraps the search function to find all users.""" - - sctrl = self.__get_server_controls__() - if sctrl is not None: - self.set_option(ldap.OPT_SERVER_CONTROLS, sctrl) try: res = self.search(*args) @@ -322,17 +271,13 @@ class IPAdmin(SimpleLDAPObject): return all_users - def getListAsync(self,*args): + def get_list_async(self,*args): """This version performs an asynchronous search, to allow results even if we hit a limit. It returns a list: counter followed by the results. If the results are truncated, counter will be set to -1. """ - - sctrl = self.__get_server_controls__() - if sctrl is not None: - self.set_option(ldap.OPT_SERVER_CONTROLS, sctrl) entries = [] partial = 0 @@ -361,15 +306,11 @@ class IPAdmin(SimpleLDAPObject): return [counter] + entries - def addEntry(self,*args): + def add_entry(self,*args): """This wraps the add function. It assumes that the entry is already populated with all of the desired objectclasses and attributes""" - sctrl = self.__get_server_controls__() - - try: - if sctrl is not None: - self.set_option(ldap.OPT_SERVER_CONTROLS, sctrl) + try: self.add_s(*args) except ldap.ALREADY_EXISTS: raise ipaerror.gen_exception(ipaerror.LDAP_DUPLICATE) @@ -377,37 +318,29 @@ class IPAdmin(SimpleLDAPObject): raise ipaerror.gen_exception(ipaerror.LDAP_DATABASE_ERROR, None, e) return "Success" - def updateRDN(self, dn, newrdn): + def update_rdn(self, dn, newrdn): """Wrap the modrdn function.""" - - sctrl = self.__get_server_controls__() if dn == newrdn: # no need to report an error return "Success" try: - if sctrl is not None: - self.set_option(ldap.OPT_SERVER_CONTROLS, sctrl) self.modrdn_s(dn, newrdn, delold=1) except ldap.LDAPError, e: raise ipaerror.gen_exception(ipaerror.LDAP_DATABASE_ERROR, None, e) return "Success" - def updateEntry(self,dn,olduser,newuser): + def update_entry(self,dn,olduser,newuser): """This wraps the mod function. It assumes that the entry is already populated with all of the desired objectclasses and attributes""" - sctrl = self.__get_server_controls__() - - modlist = self.generateModList(olduser, newuser) + modlist = self.generate_mod_list(olduser, newuser) if len(modlist) == 0: raise ipaerror.gen_exception(ipaerror.LDAP_EMPTY_MODLIST) try: - if sctrl is not None: - self.set_option(ldap.OPT_SERVER_CONTROLS, sctrl) self.modify_s(dn, modlist) # this is raised when a 'delete' attribute isn't found. # it indicates the previous attribute was removed by another @@ -418,7 +351,7 @@ class IPAdmin(SimpleLDAPObject): raise ipaerror.gen_exception(ipaerror.LDAP_DATABASE_ERROR, None, e) return "Success" - def generateModList(self, old_entry, new_entry): + def generate_mod_list(self, old_entry, new_entry): """A mod list generator that computes more precise modification lists than the python-ldap version. This version purposely generates no REPLACE operations, to deal with multi-user updates more properly.""" @@ -453,15 +386,14 @@ class IPAdmin(SimpleLDAPObject): return modlist - def inactivateEntry(self,dn,has_key): + def inactivate_entry(self,dn,has_key): """Rather than deleting entries we mark them as inactive. has_key defines whether the entry already has nsAccountlock set so we can determine which type of mod operation to run.""" - sctrl = self.__get_server_controls__() modlist=[] - if has_key == True: + if has_key: operation = ldap.MOD_REPLACE else: operation = ldap.MOD_ADD @@ -469,27 +401,21 @@ class IPAdmin(SimpleLDAPObject): modlist.append((operation, "nsAccountlock", "true")) try: - if sctrl is not None: - self.set_option(ldap.OPT_SERVER_CONTROLS, sctrl) self.modify_s(dn, modlist) except ldap.LDAPError, e: raise ipaerror.gen_exception(ipaerror.LDAP_DATABASE_ERROR, None, e) return "Success" - def deleteEntry(self,*args): + def delete_entry(self,*args): """This wraps the delete function. Use with caution.""" - sctrl = self.__get_server_controls__() - - try: - if sctrl is not None: - self.set_option(ldap.OPT_SERVER_CONTROLS, sctrl) + try: self.delete_s(*args) except ldap.LDAPError, e: raise ipaerror.gen_exception(ipaerror.LDAP_DATABASE_ERROR, None, e) return "Success" - def modifyPassword(self,dn,oldpass,newpass): + def modify_password(self,dn,oldpass,newpass): """Set the user password using RFC 3062, LDAP Password Modify Extended Operation. This ends up calling the IPA password slapi plugin handler so the Kerberos password gets set properly. @@ -497,11 +423,7 @@ class IPAdmin(SimpleLDAPObject): oldpass is not mandatory """ - sctrl = self.__get_server_controls__() - - try: - if sctrl is not None: - self.set_option(ldap.OPT_SERVER_CONTROLS, sctrl) + try: self.passwd_s(dn, oldpass, newpass) except ldap.LDAPError, e: raise ipaerror.gen_exception(ipaerror.LDAP_DATABASE_ERROR, None, e) @@ -517,18 +439,18 @@ class IPAdmin(SimpleLDAPObject): if callable(attr): setattr(self, name, wrapper(attr, name)) - def exportLDIF(self, file, suffix, forrepl=False, verbose=False): + def export_LDIF(self, file, suffix, forrepl=False, verbose=False): cn = "export" + str(int(time.time())) dn = "cn=%s, cn=export, cn=tasks, cn=config" % cn entry = Entry(dn) - entry.setValues('objectclass', 'top', 'extensibleObject') - entry.setValues('cn', cn) - entry.setValues('nsFilename', file) - entry.setValues('nsIncludeSuffix', suffix) + entry.set_values('objectclass', 'top', 'extensibleObject') + entry.set_values('cn', cn) + entry.set_values('nsFilename', file) + entry.set_values('nsIncludeSuffix', suffix) if forrepl: - entry.setValues('nsExportReplica', 'true') - - rc = self.startTaskAndWait(entry, verbose) + entry.set_values('nsExportReplica', 'true') + + rc = self.start_task_and_wait(entry, verbose) if rc: if verbose: @@ -538,7 +460,7 @@ class IPAdmin(SimpleLDAPObject): print "Export task %s for file %s completed successfully" % (cn,file) return rc - def waitForEntry(self, dn, timeout=7200, attr='', quiet=False): + def wait_for_entry(self, dn, timeout=7200, attr='', quiet=False): scope = ldap.SCOPE_BASE filter = "(objectclass=*)" attrlist = [] @@ -557,7 +479,7 @@ class IPAdmin(SimpleLDAPObject): entry = None while not entry and int(time.time()) < timeout: try: - entry = self.getEntry(dn, scope, filter, attrlist) + entry = self.get_entry(dn, scope, filter, attrlist) except ipaerror.exception_for(ipaerror.LDAP_NOT_FOUND): pass # found entry, but no attr except ldap.NO_SUCH_OBJECT: pass # no entry yet @@ -579,32 +501,32 @@ class IPAdmin(SimpleLDAPObject): return entry - def addSchema(self, attr, val): + def add_schema(self, attr, val): dn = "cn=schema" self.modify_s(dn, [(ldap.MOD_ADD, attr, val)]) - def addAttr(self, *args): - return self.addSchema('attributeTypes', args) - - def addObjClass(self, *args): - return self.addSchema('objectClasses', args) + def add_attr(self, *args): + return self.add_schema('attributeTypes', args) + + def add_obj_class(self, *args): + return self.add_schema('objectClasses', args) ########################### # Static methods start here ########################### - def normalizeDN(dn): + def normalize_dn(dn): # not great, but will do until we use a newer version of python-ldap # that has DN utilities ary = ldap.explode_dn(dn.lower()) return ",".join(ary) - normalizeDN = staticmethod(normalizeDN) + normalize_dn = staticmethod(normalize_dn) def getfqdn(name=''): return socket.getfqdn(name) getfqdn = staticmethod(getfqdn) def getdomainname(name=''): - fqdn = IPAdmin.getfqdn(name) + fqdn = LdapObject.getfqdn(name) index = fqdn.find('.') if index >= 0: return fqdn[index+1:] @@ -613,7 +535,7 @@ class IPAdmin(SimpleLDAPObject): getdomainname = staticmethod(getdomainname) def getdefaultsuffix(name=''): - dm = IPAdmin.getdomainname(name) + dm = LdapObject.getdomainname(name) if dm: return "dc=" + dm.replace('.', ', dc=') else: @@ -627,8 +549,8 @@ class IPAdmin(SimpleLDAPObject): returns True if newhost is the localhost, False otherwise""" isLocal = False if args.has_key('newhost'): - args['newhost'] = IPAdmin.getfqdn(args['newhost']) - myhost = IPAdmin.getfqdn() + args['newhost'] = LdapObject.getfqdn(args['newhost']) + myhost = LdapObject.getfqdn() if myhost == args['newhost']: isLocal = True elif args['newhost'] == 'localhost' or \ @@ -636,7 +558,7 @@ class IPAdmin(SimpleLDAPObject): isLocal = True else: isLocal = True - args['newhost'] = IPAdmin.getfqdn() + args['newhost'] = LdapObject.getfqdn() return isLocal getnewhost = staticmethod(getnewhost) diff -r 3aa0f2f6d446 -r c97541fa3a40 ipa-server/xmlrpc-server/funcs.py --- a/ipa-server/xmlrpc-server/funcs.py Tue Nov 13 15:36:52 2007 -0500 +++ b/ipa-server/xmlrpc-server/funcs.py Wed Nov 14 18:20:02 2007 -0500 @@ -68,23 +68,23 @@ class IPAConnPool: self._maxsize = maxsize self._ctx = krbV.default_context() - def getConn(self, host, port, krbccache=None, debug=None): + def get_conn(self, host, port, krbccache=None, debug=None): conn = None ccache = krbV.CCache(name=krbccache, context=self._ctx) cprinc = ccache.principal() - conn = ipaserver.ipaldap.IPAdmin(host,port,None,None,None,debug) + conn = ipaserver.ipaldap.LdapObject(host, port, None, debug) # This will bind the connection try: - conn.set_krbccache(krbccache, cprinc.name) + conn.krb_bind(krbccache, cprinc.name) except ldap.UNWILLING_TO_PERFORM, e: raise ipaerror.gen_exception(ipaerror.CONNECTION_UNWILLING) return conn - def releaseConn(self, conn): + def release_conn(self, conn): if conn is None: return @@ -124,11 +124,11 @@ class IPAServer: princ = self.__safe_filter(princ) filter = "(krbPrincipalName=" + princ + ")" # The only anonymous search we should have - conn = _LDAPPool.getConn(self.host,self.sslport,self.bindca,self.bindcert,self.bindkey,None,None,debug) - try: - ent = conn.getEntry(self.basedn, self.scope, filter, ['dn']) - finally: - _LDAPPool.releaseConn(conn) + conn = _LDAPPool.get_conn(self.host,self.sslport,self.bindca,self.bindcert,self.bindkey,None,None,debug) + try: + ent = conn.get_entry(self.basedn, self.scope, filter, ['dn']) + finally: + _LDAPPool.release_conn(conn) return "dn:" + ent.dn @@ -140,7 +140,7 @@ class IPAServer: We only want one or the other used at one time and we prefer the Kerberos credentials cache. So if there is a ccache, return - that and None for proxy dn to make calling getConn() easier. + that and None for proxy dn to make calling get_conn() easier. """ debug = "Off" @@ -163,8 +163,8 @@ class IPAServer: else: return None, self.krbccache, debug - def getConnection(self, opts): - """Wrapper around IPAConnPool.getConn() so we don't have to pass + def get_connection(self, opts): + """Wrapper around IPAConnPool.get_conn() so we don't have to pass around self.* every time a connection is needed. For SASL connections (where we have a krbccache) we can't set @@ -184,7 +184,7 @@ class IPAServer: raise ipaerror.gen_exception(ipaerror.CONNECTION_NO_CCACHE) try: - conn = _LDAPPool.getConn(self.host,port,krbccache,debug) + conn = _LDAPPool.get_conn(self.host,port,krbccache,debug) except ldap.INVALID_CREDENTIALS, e: raise ipaerror.gen_exception(ipaerror.CONNECTION_GSSAPI_CREDENTIALS, nested_exception=e) @@ -193,10 +193,10 @@ class IPAServer: return conn - def releaseConnection(self, conn): + def release_connection(self, conn): global _LDAPPool - _LDAPPool.releaseConn(conn) + _LDAPPool.release_conn(conn) def convert_entry(self, ent): entry = dict(ent.data) @@ -222,12 +222,12 @@ class IPAServer: """ ent="" - conn = self.getConnection(opts) - try: - ent = conn.getEntry(base, scope, filter, sattrs) - - finally: - self.releaseConnection(conn) + conn = self.get_connection(opts) + try: + ent = conn.get_entry(base, scope, filter, sattrs) + + finally: + self.release_connection(conn) return self.convert_entry(ent) @@ -251,11 +251,11 @@ class IPAServer: """ entries = [] - conn = self.getConnection(opts) - try: - entries = conn.getList(base, self.scope, filter, sattrs) - finally: - self.releaseConnection(conn) + conn = self.get_connection(opts) + try: + entries = conn.get_list(base, self.scope, filter, sattrs) + finally: + self.release_connection(conn) return map(self.convert_entry, entries) @@ -276,11 +276,11 @@ class IPAServer: except KeyError, e: raise ipaerror.gen_exception(ipaerror.LDAP_MISSING_DN) - conn = self.getConnection(opts) - try: - res = conn.updateEntry(moddn, oldentry, newentry) - finally: - self.releaseConnection(conn) + conn = self.get_connection(opts) + try: + res = conn.update_entry(moddn, oldentry, newentry) + finally: + self.release_connection(conn) return res def __safe_filter(self, criteria): @@ -452,19 +452,19 @@ class IPAServer: del user['gn'] # some required objectclasses - entry.setValues('objectClass', 'top', 'person', 'organizationalPerson', + entry.set_values('objectClass', 'top', 'person', 'organizationalPerson', 'inetOrgPerson', 'inetUser', 'posixAccount', 'krbPrincipalAux', 'radiusprofile') # fill in our new entry with everything sent by the user for u in user: - entry.setValues(u, user[u]) - - conn = self.getConnection(opts) - try: - res = conn.addEntry(entry) + entry.set_values(u, user[u]) + + conn = self.get_connection(opts) + try: + res = conn.add_entry(entry) self.add_user_to_group(user.get('uid'), group_dn, opts) finally: - self.releaseConnection(conn) + self.release_connection(conn) return res def get_add_schema (self): @@ -517,11 +517,11 @@ class IPAServer: """ filter = "(objectclass=posixAccount)" - conn = self.getConnection(opts) - try: - all_users = conn.getList(self.basedn, self.scope, filter, None) - finally: - self.releaseConnection(conn) + conn = self.get_connection(opts) + try: + all_users = conn.get_list(self.basedn, self.scope, filter, None) + finally: + self.release_connection(conn) users = [] for u in all_users: @@ -560,23 +560,23 @@ class IPAServer: exact_match_filter = "(&(objectClass=person)%s)" % exact_match_filter partial_match_filter = "(&(objectClass=person)%s)" % partial_match_filter - conn = self.getConnection(opts) - try: - try: - exact_results = conn.getListAsync(self.basedn, self.scope, + conn = self.get_connection(opts) + try: + try: + exact_results = conn.get_list_async(self.basedn, self.scope, exact_match_filter, sattrs, 0, None, None, timelimit, searchlimit) except ipaerror.exception_for(ipaerror.LDAP_NOT_FOUND): exact_results = [0] try: - partial_results = conn.getListAsync(self.basedn, self.scope, + partial_results = conn.get_list_async(self.basedn, self.scope, partial_match_filter, sattrs, 0, None, None, timelimit, searchlimit) except ipaerror.exception_for(ipaerror.LDAP_NOT_FOUND): partial_results = [0] finally: - self.releaseConnection(conn) + self.release_connection(conn) exact_counter = exact_results[0] partial_counter = partial_results[0] @@ -622,9 +622,9 @@ class IPAServer: if oldentry.get('uid') != newentry.get('uid'): # RDN change - conn = self.getConnection(opts) - try: - res = conn.updateRDN(oldentry.get('dn'), "uid=" + newentry.get('uid')) + conn = self.get_connection(opts) + try: + res = conn.update_rdn(oldentry.get('dn'), "uid=" + newentry.get('uid')) newdn = oldentry.get('dn') newdn = newdn.replace("uid=%s" % oldentry.get('uid'), "uid=%s" % newentry.get('uid')) @@ -635,7 +635,7 @@ class IPAServer: oldentry['uid'] = newentry['uid'] newrdn = 1 finally: - self.releaseConnection(conn) + self.release_connection(conn) try: rv = self.update_entry(oldentry, newentry, opts) @@ -660,11 +660,11 @@ class IPAServer: else: has_key = False - conn = self.getConnection(opts) - try: - res = conn.inactivateEntry(user['dn'], has_key) - finally: - self.releaseConnection(conn) + conn = self.get_connection(opts) + try: + res = conn.inactivate_entry(user['dn'], has_key) + finally: + self.release_connection(conn) return res def delete_user (self, uid, opts=None): @@ -680,11 +680,11 @@ class IPAServer: if user is None: raise ipaerror.gen_exception(ipaerror.LDAP_NOT_FOUND) - conn = self.getConnection(opts) - try: - res = conn.deleteEntry(user['dn']) - finally: - self.releaseConnection(conn) + conn = self.get_connection(opts) + try: + res = conn.delete_entry(user['dn']) + finally: + self.release_connection(conn) return res def modifyPassword (self, principal, oldpass, newpass, opts=None): @@ -698,11 +698,11 @@ class IPAServer: if user is None or user['krbprincipalname'] != principal: raise ipaerror.gen_exception(ipaerror.LDAP_NOT_FOUND) - conn = self.getConnection(opts) - try: - res = conn.modifyPassword(user['dn'], oldpass, newpass) - finally: - self.releaseConnection(conn) + conn = self.get_connection(opts) + try: + res = conn.modify_password(user['dn'], oldpass, newpass) + finally: + self.release_connection(conn) return res # Group support @@ -747,7 +747,7 @@ class IPAServer: entry = ipaserver.ipaldap.Entry(dn) # some required objectclasses - entry.setValues('objectClass', 'top', 'groupofuniquenames', 'posixGroup', + entry.set_values('objectClass', 'top', 'groupofuniquenames', 'posixGroup', 'inetUser') # No need to explicitly set gidNumber. The dna_plugin will do this @@ -755,13 +755,13 @@ class IPAServer: # fill in our new entry with everything sent by the user for g in group: - entry.setValues(g, group[g]) - - conn = self.getConnection(opts) - try: - res = conn.addEntry(entry) - finally: - self.releaseConnection(conn) + entry.set_values(g, group[g]) + + conn = self.get_connection(opts) + try: + res = conn.add_entry(entry) + finally: + self.release_connection(conn) def find_groups (self, criteria, sattrs=None, searchlimit=0, timelimit=-1, opts=None): @@ -795,23 +795,23 @@ class IPAServer: # # TODO - copy/paste from find_users. needs to be refactored # - conn = self.getConnection(opts) - try: - try: - exact_results = conn.getListAsync(self.basedn, self.scope, + conn = self.get_connection(opts) + try: + try: + exact_results = conn.get_list_async(self.basedn, self.scope, exact_match_filter, sattrs, 0, None, None, timelimit, searchlimit) except ipaerror.exception_for(ipaerror.LDAP_NOT_FOUND): exact_results = [0] try: - partial_results = conn.getListAsync(self.basedn, self.scope, + partial_results = conn.get_list_async(self.basedn, self.scope, partial_match_filter, sattrs, 0, None, None, timelimit, searchlimit) except ipaerror.exception_for(ipaerror.LDAP_NOT_FOUND): partial_results = [0] finally: - self.releaseConnection(conn) + self.release_connection(conn) exact_counter = exact_results[0] partial_counter = partial_results[0] @@ -1063,9 +1063,9 @@ class IPAServer: newcn.sort() if oldcn != newcn: # RDN change - conn = self.getConnection(opts) - try: - res = conn.updateRDN(oldentry.get('dn'), "cn=" + newcn[0]) + conn = self.get_connection(opts) + try: + res = conn.update_rdn(oldentry.get('dn'), "cn=" + newcn[0]) newdn = oldentry.get('dn') # Ick. Need to find the exact cn used in the old DN so we'll @@ -1082,7 +1082,7 @@ class IPAServer: oldentry['cn'] = newentry['cn'] newrdn = 1 finally: - self.releaseConnection(conn) + self.release_connection(conn) try: rv = self.update_entry(oldentry, newentry, opts) @@ -1106,11 +1106,11 @@ class IPAServer: if group is None: raise ipaerror.gen_exception(ipaerror.LDAP_NOT_FOUND) - conn = self.getConnection(opts) - try: - res = conn.deleteEntry(group_dn) - finally: - self.releaseConnection(conn) + conn = self.get_connection(opts) + try: + res = conn.delete_entry(group_dn) + finally: + self.release_connection(conn) return res def add_group_to_group(self, group, tgroup, opts=None): @@ -1163,15 +1163,15 @@ class IPAServer: groupdn = self.__safe_filter(groupdn) filter = "(memberOf=%s)" % groupdn - conn = self.getConnection(opts) - try: - results = conn.getListAsync(self.basedn, self.scope, + conn = self.get_connection(opts) + try: + results = conn.get_list_async(self.basedn, self.scope, filter, attr_list, 0, None, None, timelimit, searchlimit) except ipaerror.exception_for(ipaerror.LDAP_NOT_FOUND): results = [0] finally: - self.releaseConnection(conn) + self.release_connection(conn) counter = results[0] results = results[1:] From rcritten at redhat.com Thu Nov 15 04:34:17 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Nov 2007 23:34:17 -0500 Subject: [Freeipa-devel] [PATCH] group cn editable Message-ID: <473BCC49.9050705@redhat.com> Make the group cn an editable field though protected by default. Fix some issues with the multi-value to single-value reversion. This patch makes group RDN changes possible in the UI. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-398-groupfix.patch Type: text/x-patch Size: 6989 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 kmacmill at redhat.com Thu Nov 15 14:58:12 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 15 Nov 2007 09:58:12 -0500 Subject: [Freeipa-devel] new freeradius package for use with ipa In-Reply-To: <472F3DF4.2040807@redhat.com> References: <472F3DF4.2040807@redhat.com> Message-ID: <1195138692.31230.6.camel@clapton.mentalrootkit.com> On Mon, 2007-11-05 at 10:59 -0500, John Dennis wrote: > Freeradius was updated with support for kerberos sasl binds in the > rlm_ldap module. This version of freeradius should be used for testing. > > Karl: Please build the following rpm and add it to the downloads section > of freeipa: > > http://people.redhat.com/jdennis/freeradius-1.1.7-3.2.ipa.fc8.src.rpm > The srpm is up and the i386 rpm is in that F-7 repo. I'm working on resolving an error w/ the x86_64 build. Karl From kmacmill at redhat.com Thu Nov 15 14:59:36 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 15 Nov 2007 09:59:36 -0500 Subject: [Freeipa-devel] [PATCH] Password Policy suppord in ipa_pwd_extop In-Reply-To: <1194991818.1885.1.camel@hopeson> References: <1194991818.1885.1.camel@hopeson> Message-ID: <1195138776.31230.8.camel@clapton.mentalrootkit.com> On Tue, 2007-11-13 at 17:10 -0500, Simo Sorce wrote: > The patch includes all checks except password history > Will ad that with a later patch. > Pushed. From kmacmill at redhat.com Thu Nov 15 15:00:59 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 15 Nov 2007 10:00:59 -0500 Subject: [Freeipa-devel] [PATCH] finish up access control In-Reply-To: <473B197C.9070800@redhat.com> References: <473B197C.9070800@redhat.com> Message-ID: <1195138859.31230.10.camel@clapton.mentalrootkit.com> On Wed, 2007-11-14 at 10:51 -0500, Rob Crittenden wrote: > Add an editors group. This is used to generally grant access for users > to edit other users (the Edit link won't appear otherwise). > > Additional delegation is need to grant permission to individual attributes. > > Update the failed login page to indicate that it is a permission issue. > > Don't allow access to policy at all for non-admins. > > By default users can only edit themselves. > Looks good - pushed. From kmacmill at redhat.com Thu Nov 15 15:05:04 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 15 Nov 2007 10:05:04 -0500 Subject: [Freeipa-devel] [PATCH] better error message of Apache is down In-Reply-To: <473B5D44.1010706@redhat.com> References: <473B5D44.1010706@redhat.com> Message-ID: <1195139104.31230.12.camel@clapton.mentalrootkit.com> On Wed, 2007-11-14 at 15:40 -0500, Rob Crittenden wrote: > If unable to connect to the XML-RPC server print a more useful error msg. > > I also noticed that some cmd-line tools were missing some error > handling. Added that too. > > rob I'd prefer a symbolic name rather than 111 everywhere. Karl From kmacmill at redhat.com Thu Nov 15 15:05:56 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 15 Nov 2007 10:05:56 -0500 Subject: [Freeipa-devel] [PATCH] group cn editable In-Reply-To: <473BCC49.9050705@redhat.com> References: <473BCC49.9050705@redhat.com> Message-ID: <1195139156.31230.14.camel@clapton.mentalrootkit.com> On Wed, 2007-11-14 at 23:34 -0500, Rob Crittenden wrote: > Make the group cn an editable field though protected by default. > Fix some issues with the multi-value to single-value reversion. > > This patch makes group RDN changes possible in the UI. > Looks good - pushed. From kmacmill at redhat.com Thu Nov 15 15:06:24 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 15 Nov 2007 10:06:24 -0500 Subject: [Freeipa-devel] [PATCH] fix FQDN error during install In-Reply-To: <473A2ABB.5030505@redhat.com> References: <473A2ABB.5030505@redhat.com> Message-ID: <1195139184.31230.16.camel@clapton.mentalrootkit.com> On Tue, 2007-11-13 at 17:52 -0500, Rob Crittenden wrote: > I forgot to include FQDN in the substition list in httpinstance.py so > ipa-server-install would fail. > > rob Pushed. From kmacmill at redhat.com Thu Nov 15 15:07:12 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 15 Nov 2007 10:07:12 -0500 Subject: [Freeipa-devel] [PATCH] make unauthorized page generic In-Reply-To: <473B467B.8060108@redhat.com> References: <473B467B.8060108@redhat.com> Message-ID: <1195139232.31230.18.camel@clapton.mentalrootkit.com> On Wed, 2007-11-14 at 14:03 -0500, Rob Crittenden wrote: > Remove reference to idm wiki and make the unauthorized page generic. > Looks good. > It is installed into /usr/share/ipa/html so can be customized as desired > by end-users. > If we expect editing we should move this to /etc/ipa and mark it as config in the rpm, right? Pushed. Karl From rcritten at redhat.com Thu Nov 15 15:27:53 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Nov 2007 10:27:53 -0500 Subject: [Freeipa-devel] [PATCH] better error message of Apache is down In-Reply-To: <1195139104.31230.12.camel@clapton.mentalrootkit.com> References: <473B5D44.1010706@redhat.com> <1195139104.31230.12.camel@clapton.mentalrootkit.com> Message-ID: <473C6579.3030406@redhat.com> Karl MacMillan wrote: > On Wed, 2007-11-14 at 15:40 -0500, Rob Crittenden wrote: >> If unable to connect to the XML-RPC server print a more useful error msg. >> >> I also noticed that some cmd-line tools were missing some error >> handling. Added that too. >> >> rob > > I'd prefer a symbolic name rather than 111 everywhere. > > Karl > Fixed. New patch attached. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-402-errmsg.patch Type: text/x-patch Size: 12511 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 Nov 15 15:29:06 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Nov 2007 10:29:06 -0500 Subject: [Freeipa-devel] [PATCH] make unauthorized page generic In-Reply-To: <1195139232.31230.18.camel@clapton.mentalrootkit.com> References: <473B467B.8060108@redhat.com> <1195139232.31230.18.camel@clapton.mentalrootkit.com> Message-ID: <473C65C2.4090009@redhat.com> Karl MacMillan wrote: > On Wed, 2007-11-14 at 14:03 -0500, Rob Crittenden wrote: >> Remove reference to idm wiki and make the unauthorized page generic. >> > > Looks good. > >> It is installed into /usr/share/ipa/html so can be customized as desired >> by end-users. >> > > If we expect editing we should move this to /etc/ipa and mark it as > config in the rpm, right? > If we move the file we'd need to change the httpd ipa.conf as well. I think we can still mark it as config in the rpm and leave it where it is. 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 Thu Nov 15 15:57:45 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Nov 2007 10:57:45 -0500 Subject: [Freeipa-devel] [PATCH] update freeipa-server spec file Message-ID: <473C6C79.8050609@redhat.com> Broke invididual Requires and BuildRequires onto separate lines and reordered them Added python-tgexpandingformwidget as a dependency Require at least fedora-ds-base 1.1 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-403-spec.patch Type: text/x-patch Size: 5095 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 kmacmill at redhat.com Thu Nov 15 16:09:05 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 15 Nov 2007 11:09:05 -0500 Subject: [Freeipa-devel] [PATCH] post install memberof task In-Reply-To: <4739FB75.801@redhat.com> References: <472FB5CF.6060103@redhat.com> <4731D134.8010904@redhat.com> <47321CB2.7020205@redhat.com> <47321E2C.2000704@redhat.com> <1194622535.3246.29.camel@clapton.mentalrootkit.com> <4734B553.508@redhat.com> <1194977227.9034.0.camel@clapton.mentalrootkit.com> <4739FB75.801@redhat.com> Message-ID: <1195142945.31230.35.camel@clapton.mentalrootkit.com> On Tue, 2007-11-13 at 11:31 -0800, Pete Rowley wrote: > Karl MacMillan wrote: > > On Fri, 2007-11-09 at 11:30 -0800, Pete Rowley wrote: > > > >> Karl MacMillan wrote: > >> > >>>> I didn't try it but our call to ldapmodify doesn't include -a and the > >>>> ldif doesn't have a changetype, so I assumed it would crap out. > >>>> > >>>> > >>> Pete - any resolution on this? Should I import the patch or not? > >>> > >>> > >> It worked ok when I tested it so lets import. > >> > >> > > > > Doesn't work for me - I get: > > > > [14/11]: initializing group membership > > root : CRITICAL Failed to load memberof-conf.ldif: Command > > '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w box > > -f /tmp/tmp_sqh6R' returned non-zero exit status 32 > > > Does the behavior change when you insert changetype: add? > Yes - actually committed the attached which also updates the number of tasks. -------------- next part -------------- # HG changeset patch # User "Karl MacMillan " # Date 1195142883 18000 # Node ID 499535ab1275e620e58f23dc4b6853966fa989f9 # Parent 195a46fc42ce03467937518f2d222efdda6fe363 Initialize memberof patch from Pete Rowley. diff -r 195a46fc42ce -r 499535ab1275 ipa-server/ipa-install/share/Makefile.am --- a/ipa-server/ipa-install/share/Makefile.am Wed Nov 14 14:11:29 2007 -0500 +++ b/ipa-server/ipa-install/share/Makefile.am Thu Nov 15 11:08:03 2007 -0500 @@ -22,6 +22,7 @@ app_DATA = \ referint-conf.ldif \ dna-posix.ldif \ master-entry.ldif \ + memberof-task.ldif \ $(NULL) EXTRA_DIST = \ diff -r 195a46fc42ce -r 499535ab1275 ipa-server/ipaserver/dsinstance.py --- a/ipa-server/ipaserver/dsinstance.py Wed Nov 14 14:11:29 2007 -0500 +++ b/ipa-server/ipaserver/dsinstance.py Thu Nov 15 11:08:03 2007 -0500 @@ -34,6 +34,9 @@ def ldap_mod(fd, dn, pwd): def ldap_mod(fd, dn, pwd): args = ["/usr/bin/ldapmodify", "-h", "127.0.0.1", "-xv", "-D", dn, "-w", pwd, "-f", fd.name] run(args) + + text = fd.read() + print text def realm_to_suffix(realm_name): s = realm_name.split(".") @@ -78,7 +81,7 @@ class DsInstance(service.Service): self.dm_password = dm_password self.__setup_sub_dict() - self.start_creation(11, "Configuring directory server:") + self.start_creation(15, "Configuring directory server:") self.__create_ds_user() self.__create_instance() self.__add_default_schemas() @@ -97,6 +100,7 @@ class DsInstance(service.Service): self.__config_uidgid_gen_first_master() self.__add_default_layout() self.__add_master_entry_first_master() + self.__init_memberof() self.step("configuring directoy to start on boot") @@ -177,6 +181,16 @@ class DsInstance(service.Service): logging.critical("Failed to load memberof-conf.ldif: %s" % str(e)) memberof_fd.close() + def __init_memberof(self): + self.step("initializing group membership") + memberof_txt = template_file(SHARE_DIR + "memberof-task.ldif", self.sub_dict) + memberof_fd = write_tmp_file(memberof_txt) + try: + ldap_mod(memberof_fd, "cn=Directory Manager", self.dm_password) + except subprocess.CalledProcessError, e: + logging.critical("Failed to load memberof-conf.ldif: %s" % str(e)) + memberof_fd.close() + def __add_referint_module(self): self.step("enabling referential integrity plugin") referint_txt = template_file(SHARE_DIR + "referint-conf.ldif", self.sub_dict) From rcritten at redhat.com Thu Nov 15 16:09:47 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Nov 2007 11:09:47 -0500 Subject: [Freeipa-devel] [PATCH] Don't silently fail on non-existant file Message-ID: <473C6F4B.8030709@redhat.com> The function update_file() would fail silently if the file it was to update didn't exist. Print and return an error now. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-404-exist.patch Type: text/x-patch Size: 1159 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 Thu Nov 15 16:23:07 2007 From: jdennis at redhat.com (John Dennis) Date: Thu, 15 Nov 2007 11:23:07 -0500 Subject: [Freeipa-devel] get_entry_by_dn() in client requires prior search Message-ID: <473C726B.9060000@redhat.com> get_entry_by_dn() cannot be called from the client side unless you've previously done a search that returns an Entity with the dn in it. But why have to do a search first if you already know or can compute the dn, why not just call get_entry_by_dn()? The reason you can't call get_entry_by_dn() from a client is you don't know the suffix. How about if IPAServer.get_entry_by_dn() checked for the suffix in the dn, if it were missing it would added it for you. Anybody see a problem with that? This would also reduce the need to write a lot of get_entry_by_XXX() functions because in many cases the caller of that search knows a prioi what the dn would be, just not the suffix. BTW, we could add an rpc function to return the suffix in order to build the dn, but that would introduce an unnecessary round trip and negating the advantage. -- John Dennis From kmacmill at redhat.com Thu Nov 15 16:26:01 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 15 Nov 2007 11:26:01 -0500 Subject: [Freeipa-devel] [PATCH] better error message of Apache is down In-Reply-To: <473C6579.3030406@redhat.com> References: <473B5D44.1010706@redhat.com> <1195139104.31230.12.camel@clapton.mentalrootkit.com> <473C6579.3030406@redhat.com> Message-ID: <1195143961.31230.43.camel@clapton.mentalrootkit.com> On Thu, 2007-11-15 at 10:27 -0500, Rob Crittenden wrote: > Karl MacMillan wrote: > > On Wed, 2007-11-14 at 15:40 -0500, Rob Crittenden wrote: > >> If unable to connect to the XML-RPC server print a more useful error msg. > >> > >> I also noticed that some cmd-line tools were missing some error > >> handling. Added that too. > >> > >> rob > > > > I'd prefer a symbolic name rather than 111 everywhere. > > > > Karl > > > > Fixed. New patch attached. > Thanks - pushed. Karl From kmacmill at redhat.com Thu Nov 15 16:29:10 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 15 Nov 2007 11:29:10 -0500 Subject: [Freeipa-devel] [PATCH] make unauthorized page generic In-Reply-To: <473C65C2.4090009@redhat.com> References: <473B467B.8060108@redhat.com> <1195139232.31230.18.camel@clapton.mentalrootkit.com> <473C65C2.4090009@redhat.com> Message-ID: <1195144150.31230.46.camel@clapton.mentalrootkit.com> On Thu, 2007-11-15 at 10:29 -0500, Rob Crittenden wrote: > Karl MacMillan wrote: > > On Wed, 2007-11-14 at 14:03 -0500, Rob Crittenden wrote: > >> Remove reference to idm wiki and make the unauthorized page generic. > >> > > > > Looks good. > > > >> It is installed into /usr/share/ipa/html so can be customized as desired > >> by end-users. > >> > > > > If we expect editing we should move this to /etc/ipa and mark it as > > config in the rpm, right? > > > > If we move the file we'd need to change the httpd ipa.conf as well. I > think we can still mark it as config in the rpm and leave it where it is. > Ick if you ask me - re-opened the ticket and moved it to release 1 to track this. Karl From kmacmill at redhat.com Thu Nov 15 16:30:17 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 15 Nov 2007 11:30:17 -0500 Subject: [Freeipa-devel] [PATCH] update freeipa-server spec file In-Reply-To: <473C6C79.8050609@redhat.com> References: <473C6C79.8050609@redhat.com> Message-ID: <1195144217.31230.48.camel@clapton.mentalrootkit.com> On Thu, 2007-11-15 at 10:57 -0500, Rob Crittenden wrote: > Broke invididual Requires and BuildRequires onto separate lines and > reordered them > Added python-tgexpandingformwidget as a dependency > Require at least fedora-ds-base 1.1 > Pushed - this removes our need to patch the DS init script. David, could you update the docs to remove that information? Thanks - Karl From kmacmill at redhat.com Thu Nov 15 16:30:50 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 15 Nov 2007 11:30:50 -0500 Subject: [Freeipa-devel] [PATCH] Don't silently fail on non-existant file In-Reply-To: <473C6F4B.8030709@redhat.com> References: <473C6F4B.8030709@redhat.com> Message-ID: <1195144250.31230.50.camel@clapton.mentalrootkit.com> On Thu, 2007-11-15 at 11:09 -0500, Rob Crittenden wrote: > The function update_file() would fail silently if the file it was to > update didn't exist. Print and return an error now. > Pushed. Karl From rcritten at redhat.com Thu Nov 15 16:44:01 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Nov 2007 11:44:01 -0500 Subject: [Freeipa-devel] get_entry_by_dn() in client requires prior search In-Reply-To: <473C726B.9060000@redhat.com> References: <473C726B.9060000@redhat.com> Message-ID: <473C7751.8000403@redhat.com> John Dennis wrote: > get_entry_by_dn() cannot be called from the client side unless you've > previously done a search that returns an Entity with the dn in it. > > But why have to do a search first if you already know or can compute the > dn, why not just call get_entry_by_dn()? > > The reason you can't call get_entry_by_dn() from a client is you don't > know the suffix. > > How about if IPAServer.get_entry_by_dn() checked for the suffix in the > dn, if it were missing it would added it for you. Anybody see a problem > with that? Just the baseDN or some other part of the tree? It still might end up failing as we don't advertise that users are in cn=accounts and groups in cn=groups. Perhaps we need a get_entry_by_attr(value, attr) which does a search for 'attr=value' and returns whatever is found. > This would also reduce the need to write a lot of get_entry_by_XXX() > functions because in many cases the caller of that search knows a prioi > what the dn would be, just not the suffix. > > BTW, we could add an rpc function to return the suffix in order to build > the dn, but that would introduce an unnecessary round trip and negating > the advantage. Yup, though that is probably computable based on the domain since it is always dc=domain,dc=foo. 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 david.obrien at redhat.com Thu Nov 15 17:01:10 2007 From: david.obrien at redhat.com (David O'Brien) Date: Fri, 16 Nov 2007 03:01:10 +1000 Subject: [Freeipa-devel] [PATCH] update freeipa-server spec file In-Reply-To: <1195144217.31230.48.camel@clapton.mentalrootkit.com> References: <473C6C79.8050609@redhat.com> <1195144217.31230.48.camel@clapton.mentalrootkit.com> Message-ID: <473C7B56.1040901@redhat.com> Karl MacMillan wrote: > On Thu, 2007-11-15 at 10:57 -0500, Rob Crittenden wrote: >> Broke invididual Requires and BuildRequires onto separate lines and >> reordered them >> Added python-tgexpandingformwidget as a dependency >> Require at least fedora-ds-base 1.1 >> > > Pushed - this removes our need to patch the DS init script. David, could > you update the docs to remove that information? > > Thanks - Karl > > Removed. -- David O'Brien RHCT PGP-KeyID: 0x443CBA7B -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jdennis at redhat.com Thu Nov 15 17:01:48 2007 From: jdennis at redhat.com (John Dennis) Date: Thu, 15 Nov 2007 12:01:48 -0500 Subject: [Freeipa-devel] get_entry_by_dn() in client requires prior search In-Reply-To: <473C7751.8000403@redhat.com> References: <473C726B.9060000@redhat.com> <473C7751.8000403@redhat.com> Message-ID: <473C7B7C.9000104@redhat.com> Rob Crittenden wrote: > Just the baseDN or some other part of the tree? It still might end up > failing as we don't advertise that users are in cn=accounts and groups > in cn=groups. No, we don't advertise it, but the command line tools are pretty tightly integrated with the rest of the system and dn's are getting passed around a lot, but I appreciate your point, it makes sense. > Perhaps we need a get_entry_by_attr(value, attr) which does a search for > 'attr=value' and returns whatever is found. I'm not sure attr=value is sufficiently specific, but if it included an objectclass it would probably be O.K. But there is still no guarantee of what might get returned. Plus it would be inefficient, it would have to search from the root. The appeal of get_entry_by_dn() is avoiding a search and avoiding a proliferation of get_entry_by_XXX rpc calls but I guess that's the only solution if you want to hide the ldap structure in IPAServer. -- John Dennis From david.obrien at redhat.com Thu Nov 15 17:07:52 2007 From: david.obrien at redhat.com (David O'Brien) Date: Fri, 16 Nov 2007 03:07:52 +1000 Subject: [Freeipa-devel] Error updating group membership Message-ID: <473C7CE8.6010400@redhat.com> Running on 32-bit F7 I created a "regular" user as admin, and then logged on as that user from the client. I tried to add myself to "ipausers" but received "There was an error updating groups. Failures have been preserved in the add/remove lists." I assume this means I can't add myself to the ipausers group, but it doesn't really say why (e.g. Insufficient permissions). What and where are the "add/remove lists"? I want to ask, "Can we show which groups a user is allowed to interact with (i.e. join/leave)" but I remember rcrit I think saying we don't check this stuff until you hit Submit. Pity. -- David O'Brien RHCT PGP-KeyID: 0x443CBA7B -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From rcritten at redhat.com Thu Nov 15 17:07:49 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Nov 2007 12:07:49 -0500 Subject: [Freeipa-devel] get_entry_by_dn() in client requires prior search In-Reply-To: <473C7B7C.9000104@redhat.com> References: <473C726B.9060000@redhat.com> <473C7751.8000403@redhat.com> <473C7B7C.9000104@redhat.com> Message-ID: <473C7CE5.7090902@redhat.com> John Dennis wrote: > Rob Crittenden wrote: >> Just the baseDN or some other part of the tree? It still might end up >> failing as we don't advertise that users are in cn=accounts and groups >> in cn=groups. > > No, we don't advertise it, but the command line tools are pretty tightly > integrated with the rest of the system and dn's are getting passed > around a lot, but I appreciate your point, it makes sense. > >> Perhaps we need a get_entry_by_attr(value, attr) which does a search >> for 'attr=value' and returns whatever is found. > > I'm not sure attr=value is sufficiently specific, but if it included an > objectclass it would probably be O.K. But there is still no guarantee of > what might get returned. Plus it would be inefficient, it would have to > search from the root. The appeal of get_entry_by_dn() is avoiding a > search and avoiding a proliferation of get_entry_by_XXX rpc calls but I > guess that's the only solution if you want to hide the ldap structure in > IPAServer. > We could really open it up by letting you pass in a full filter but I suspect that is fairly dangerous. What is it you're searching for? 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 david.obrien at redhat.com Thu Nov 15 17:36:50 2007 From: david.obrien at redhat.com (David O'Brien) Date: Fri, 16 Nov 2007 03:36:50 +1000 Subject: [Freeipa-devel] Error updating group membership In-Reply-To: <473C7CE8.6010400@redhat.com> References: <473C7CE8.6010400@redhat.com> Message-ID: <473C83B2.7010506@redhat.com> David O'Brien wrote: > Running on 32-bit F7 > > I created a "regular" user as admin, and then logged on as that user > from the client. I tried to add myself to "ipausers" but received "There > was an error updating groups. Failures have been preserved in the > add/remove lists." > > I assume this means I can't add myself to the ipausers group, but it > doesn't really say why (e.g. Insufficient permissions). > > What and where are the "add/remove lists"? > > I want to ask, "Can we show which groups a user is allowed to interact > with (i.e. join/leave)" but I remember rcrit I think saying we don't > check this stuff until you hit Submit. Pity. > > On a related note, if you attempt to add a group as a regular user, you get an extensive error message: Group add failed: A database error occurred {'info': "Insufficient 'add' privilege to add the entry...} etc. Much more informative, but not that pretty. -- David O'Brien RHCT PGP-KeyID: 0x443CBA7B -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From kmacmill at redhat.com Thu Nov 15 17:42:37 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 15 Nov 2007 12:42:37 -0500 Subject: [Freeipa-devel] Error updating group membership In-Reply-To: <473C83B2.7010506@redhat.com> References: <473C7CE8.6010400@redhat.com> <473C83B2.7010506@redhat.com> Message-ID: <1195148557.31230.64.camel@clapton.mentalrootkit.com> On Fri, 2007-11-16 at 03:36 +1000, David O'Brien wrote: > David O'Brien wrote: > > Running on 32-bit F7 > > > > I created a "regular" user as admin, and then logged on as that user > > from the client. I tried to add myself to "ipausers" but received "There > > was an error updating groups. Failures have been preserved in the > > add/remove lists." > > > > I assume this means I can't add myself to the ipausers group, but it > > doesn't really say why (e.g. Insufficient permissions). > > > > What and where are the "add/remove lists"? > > > > I want to ask, "Can we show which groups a user is allowed to interact > > with (i.e. join/leave)" but I remember rcrit I think saying we don't > > check this stuff until you hit Submit. Pity. > > > > > > On a related note, if you attempt to add a group as a regular user, you > get an extensive error message: Group add failed: A database error > occurred {'info': "Insufficient 'add' privilege to add the entry...} etc. > > Much more informative, but not that pretty. The add links are going away for users that aren't able to actually do the add. Karl From rcritten at redhat.com Thu Nov 15 18:05:55 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Nov 2007 13:05:55 -0500 Subject: [Freeipa-devel] Error updating group membership In-Reply-To: <473C83B2.7010506@redhat.com> References: <473C7CE8.6010400@redhat.com> <473C83B2.7010506@redhat.com> Message-ID: <473C8A83.10100@redhat.com> David O'Brien wrote: > David O'Brien wrote: >> Running on 32-bit F7 >> >> I created a "regular" user as admin, and then logged on as that user >> from the client. I tried to add myself to "ipausers" but received "There >> was an error updating groups. Failures have been preserved in the >> add/remove lists." >> >> I assume this means I can't add myself to the ipausers group, but it >> doesn't really say why (e.g. Insufficient permissions). >> >> What and where are the "add/remove lists"? >> >> I want to ask, "Can we show which groups a user is allowed to interact >> with (i.e. join/leave)" but I remember rcrit I think saying we don't >> check this stuff until you hit Submit. Pity. >> >> > > On a related note, if you attempt to add a group as a regular user, you > get an extensive error message: Group add failed: A database error > occurred {'info': "Insufficient 'add' privilege to add the entry...} etc. > > Much more informative, but not that pretty. Can you open a bug on the extensiveness of the message :-) And really, a non-admin user should only see Find Users and Groups and Self-Service now. 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 Thu Nov 15 18:13:54 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Nov 2007 13:13:54 -0500 Subject: [Freeipa-devel] [PATCH] Replace People and Person with Users and User Message-ID: <473C8C62.3040600@redhat.com> Replace People and Person with Users and User in the UI. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-410-people.patch Type: text/x-patch Size: 9231 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 david.obrien at redhat.com Thu Nov 15 18:25:27 2007 From: david.obrien at redhat.com (David O'Brien) Date: Fri, 16 Nov 2007 04:25:27 +1000 Subject: [Freeipa-devel] what attributes are indexed for searches? Message-ID: <473C8F17.2040902@redhat.com> how can I get a list of the attributes that a user can search on? Or even, can't search on. thanks -- David O'Brien RHCT PGP-KeyID: 0x443CBA7B -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From ssorce at redhat.com Thu Nov 15 18:32:53 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 15 Nov 2007 13:32:53 -0500 Subject: [Freeipa-devel] Re: things to be stored In-Reply-To: <473A0486.2040206@redhat.com> References: <472B47C7.8030106@redhat.com> <473A0486.2040206@redhat.com> Message-ID: <1195151573.8978.66.camel@localhost.localdomain> On Tue, 2007-11-13 at 15:09 -0500, Rob Crittenden wrote: > Rob Crittenden wrote: > > I could care less how the configuration is stored in LDAP, either as a > > extensibleObject or with its own schema, but here is the stuff I need > > stored somewhere: > > > > userSearchFields, a list of attributes e.g. > > uid,givenName,sn,telephoneNumber,ou,title > > > > searchTimeLimit, an integer, e.g. 2 > > > > customFields, a set of tuple of the form (label, attribute, required). > > All are strings. required is a boolean but will contain "true" or > > "false". This needs to be extensible as at some point we'll add a > > validator as well, and who knows what else, maybe things to limit field > > length, min/max size, etc. > > > > The current hardcoded version, in python, looks like: > > > > schema = [ > > { 'label': 'See Also', > > 'field': 'seeAlso', > > 'required': 'true', } , > > { 'label': 'O O O', > > 'field': 'o', > > 'required': 'false', } , > > ] > > > > Another thing we need to think about is how I'll fetch this from the > > server. Currently all requests to the server need to be authenticated > > but it would probably be better performance-wise to grab this at startup > > time. So should we allow unauthenticated requests to the XML-RPC > > interface? Currently the whole thing requires SSL and kerberos. > > Found some more things to store: > > - root of home directory (e.g. /home, /u, /export1/home, whatever) > - default shell (going with /bin/bash by default) > - default group that new users are automatically added to (ipausers by > default) This schema might do it: http://simo.fedorapeople.org/ipa-config-schema.ldif Rich I'd like a comment from you as well if you have time. Simo. From rmeggins at redhat.com Thu Nov 15 18:41:00 2007 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 15 Nov 2007 11:41:00 -0700 Subject: [Freeipa-devel] Re: things to be stored In-Reply-To: <1195151573.8978.66.camel@localhost.localdomain> References: <472B47C7.8030106@redhat.com> <473A0486.2040206@redhat.com> <1195151573.8978.66.camel@localhost.localdomain> Message-ID: <473C92BC.6040905@redhat.com> Simo Sorce wrote: > On Tue, 2007-11-13 at 15:09 -0500, Rob Crittenden wrote: > >> Rob Crittenden wrote: >> >>> I could care less how the configuration is stored in LDAP, either as a >>> extensibleObject or with its own schema, but here is the stuff I need >>> stored somewhere: >>> >>> userSearchFields, a list of attributes e.g. >>> uid,givenName,sn,telephoneNumber,ou,title >>> >>> searchTimeLimit, an integer, e.g. 2 >>> >>> customFields, a set of tuple of the form (label, attribute, required). >>> All are strings. required is a boolean but will contain "true" or >>> "false". This needs to be extensible as at some point we'll add a >>> validator as well, and who knows what else, maybe things to limit field >>> length, min/max size, etc. >>> >>> The current hardcoded version, in python, looks like: >>> >>> schema = [ >>> { 'label': 'See Also', >>> 'field': 'seeAlso', >>> 'required': 'true', } , >>> { 'label': 'O O O', >>> 'field': 'o', >>> 'required': 'false', } , >>> ] >>> >>> Another thing we need to think about is how I'll fetch this from the >>> server. Currently all requests to the server need to be authenticated >>> but it would probably be better performance-wise to grab this at startup >>> time. So should we allow unauthenticated requests to the XML-RPC >>> interface? Currently the whole thing requires SSL and kerberos. >>> >> Found some more things to store: >> >> - root of home directory (e.g. /home, /u, /export1/home, whatever) >> - default shell (going with /bin/bash by default) >> - default group that new users are automatically added to (ipausers by >> default) >> > > > This schema might do it: > http://simo.fedorapeople.org/ipa-config-schema.ldif > > Rich I'd like a comment from you as well if you have time. > Looks good. It looks similar to the DUA Config Profile schema - http://tools.ietf.org/html/rfc4876 > Simo. > > -------------- 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 prowley at redhat.com Thu Nov 15 19:10:13 2007 From: prowley at redhat.com (Pete Rowley) Date: Thu, 15 Nov 2007 11:10:13 -0800 Subject: [Freeipa-devel] get_entry_by_dn() in client requires prior search In-Reply-To: <473C7B7C.9000104@redhat.com> References: <473C726B.9060000@redhat.com> <473C7751.8000403@redhat.com> <473C7B7C.9000104@redhat.com> Message-ID: <473C9995.8000906@redhat.com> John Dennis wrote: > I'm not sure attr=value is sufficiently specific, but if it included > an objectclass it would probably be O.K. But there is still no > guarantee of what might get returned. Plus it would be inefficient, > it would have to search from the root. If your search is indexed (which it should be) and resolves to a single entry then the timing difference between a base level search on a dn and a subtree search from the suffix will be negligible to unmeasurable. -- Pete -------------- 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 rcritten at redhat.com Thu Nov 15 19:20:53 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Nov 2007 14:20:53 -0500 Subject: [Freeipa-devel] [PATCH] use same labels as UI in output for ipa-finduser and ipa-findgroup Message-ID: <473C9C15.2050902@redhat.com> Use same labels as UI for ipa-finduser and ipa-findgroup Add -a option to ipa-findgroup to print all attributes Karl opened a ticket on this today and while it doesn't need to happen by tomorrow I already had this in one of my trees. More work is needed on other utilities, I'll punt on that for now. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-411-labels.patch Type: text/x-patch Size: 3830 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 Nov 15 19:40:18 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Nov 2007 14:40:18 -0500 Subject: [Freeipa-devel] [PATCH] completely remove attributes Message-ID: <473CA0A2.9030703@redhat.com> This lets ipa-usermod completely remove an attribute (as opposed to setting it to ''). rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-412-delattr.patch Type: text/x-patch Size: 1401 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 Nov 15 19:45:06 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Nov 2007 14:45:06 -0500 Subject: [Freeipa-devel] [PATCH] Remove attributes for groups too Message-ID: <473CA1C2.1030307@redhat.com> It occurred to me after I sent the previous patch that we can remove attributes for groups too. Here is the patch for that. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-413-delattr.patch Type: text/x-patch Size: 2540 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 Nov 15 21:25:47 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Nov 2007 16:25:47 -0500 Subject: [Freeipa-devel] Re: things to be stored In-Reply-To: <1195151573.8978.66.camel@localhost.localdomain> References: <472B47C7.8030106@redhat.com> <473A0486.2040206@redhat.com> <1195151573.8978.66.camel@localhost.localdomain> Message-ID: <473CB95B.8060300@redhat.com> Simo Sorce wrote: > > This schema might do it: > http://simo.fedorapeople.org/ipa-config-schema.ldif > > Rich I'd like a comment from you as well if you have time. > This is working fine but, of course, I need more. I need: ipaGroupSearchFields ipaSearchLimit (# of records to search as opposed to a time limit) I've implemented ipaUserSearchFields, ipaSearchTimeLimit, ipaHomesRootDir. ipaDefaultLoginShell and ipaDefaultPrimaryGroup on the server side (e.g. it fetches the config and uses the values). Just need to do custom fields and finish the UI to edit these values. 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 Thu Nov 15 21:56:56 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 15 Nov 2007 16:56:56 -0500 Subject: [Freeipa-devel] Re: things to be stored In-Reply-To: <473CB95B.8060300@redhat.com> References: <472B47C7.8030106@redhat.com> <473A0486.2040206@redhat.com> <1195151573.8978.66.camel@localhost.localdomain> <473CB95B.8060300@redhat.com> Message-ID: <1195163816.24778.0.camel@localhost.localdomain> On Thu, 2007-11-15 at 16:25 -0500, Rob Crittenden wrote: > Simo Sorce wrote: > > > > This schema might do it: > > http://simo.fedorapeople.org/ipa-config-schema.ldif > > > > Rich I'd like a comment from you as well if you have time. > > > > This is working fine but, of course, I need more. > > I need: > > ipaGroupSearchFields > ipaSearchLimit (# of records to search as opposed to a time limit) Ok I updated the file on http://simo.fedorapeople.org/ipa-config-schema.ldif > I've implemented ipaUserSearchFields, ipaSearchTimeLimit, > ipaHomesRootDir. ipaDefaultLoginShell and ipaDefaultPrimaryGroup on the > server side (e.g. it fetches the config and uses the values). > > Just need to do custom fields and finish the UI to edit these values. Great, Simo. From rcritten at redhat.com Fri Nov 16 04:31:31 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Nov 2007 23:31:31 -0500 Subject: [Freeipa-devel] Re: things to be stored In-Reply-To: <1195163816.24778.0.camel@localhost.localdomain> References: <472B47C7.8030106@redhat.com> <473A0486.2040206@redhat.com> <1195151573.8978.66.camel@localhost.localdomain> <473CB95B.8060300@redhat.com> <1195163816.24778.0.camel@localhost.localdomain> Message-ID: <473D1D23.9040203@redhat.com> Simo Sorce wrote: > On Thu, 2007-11-15 at 16:25 -0500, Rob Crittenden wrote: >> Simo Sorce wrote: >>> This schema might do it: >>> http://simo.fedorapeople.org/ipa-config-schema.ldif >>> >>> Rich I'd like a comment from you as well if you have time. >>> >> This is working fine but, of course, I need more. >> >> I need: >> >> ipaGroupSearchFields >> ipaSearchLimit (# of records to search as opposed to a time limit) > > Ok I updated the file on > http://simo.fedorapeople.org/ipa-config-schema.ldif > >> I've implemented ipaUserSearchFields, ipaSearchTimeLimit, >> ipaHomesRootDir. ipaDefaultLoginShell and ipaDefaultPrimaryGroup on the >> server side (e.g. it fetches the config and uses the values). >> >> Just need to do custom fields and finish the UI to edit these values. > > Great, > Simo. > Ok, I think one more iteration will do it. Need 2 more: ipaMaxUidLength - max length of a uid ipaPasswordNotif - # of days before a password expires to notify users (in GUI or otherwise) 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 Nov 16 15:40:25 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 16 Nov 2007 10:40:25 -0500 Subject: [Freeipa-devel] search fields Message-ID: <473DB9E9.9070300@redhat.com> I have a memory of talking about this before but can't find the e-mails. I'm working on policy configuration now and setting the default search fields. They are: users: uid,givenName,sn,telephoneNumber,ou,title groups: cn,description If you want additional fields speak now :-) I seem to recall discussing add carLicense and displayname. 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 jdennis at redhat.com Fri Nov 16 15:55:38 2007 From: jdennis at redhat.com (John Dennis) Date: Fri, 16 Nov 2007 10:55:38 -0500 Subject: [Freeipa-devel] containers Message-ID: <473DBD7A.7010800@redhat.com> From reading the code in funcs.py I think we might have collision/ambiguity problem. The code seems a bit schizophrenic about specifying the container in which to search. In many instances a search will just start at the suffix and makes the assumption the attribute it is searching for is unique, that is probably not a good assumption if you have more than one container in the tree. The add_{user,group}() methods take an optional container parameter but the __is_{user,group}_unique() methods ignore it and just search from the root. The same holds true for the get_XXX_by_XXX() methods. If there is more than one container in the tree we'll end up with inconsistent results. Will we ever have more than one container for things? Yes. For instance radius wants to have containers under services. I'm afraid some of the root based searches could end up finding things there instead. Whether or not this is true for specific pieces of radius data (I have not verified this due to bad searches) it just seems like a lurking problem and potential source of bugs, especially as more and more data gets added to the tree and hung off of different container nodes. Shouldn't the functions performing searches always specify the container they are searching under? -- John Dennis From david.obrien at redhat.com Fri Nov 16 16:16:20 2007 From: david.obrien at redhat.com (David O'Brien) Date: Sat, 17 Nov 2007 02:16:20 +1000 Subject: [Freeipa-devel] search fields In-Reply-To: <473DB9E9.9070300@redhat.com> References: <473DB9E9.9070300@redhat.com> Message-ID: <473DC254.8020806@redhat.com> Rob Crittenden wrote: > I have a memory of talking about this before but can't find the e-mails. > > I'm working on policy configuration now and setting the default search > fields. They are: > > users: uid,givenName,sn,telephoneNumber,ou,title > groups: cn,description > > If you want additional fields speak now :-) > > I seem to recall discussing add carLicense and displayname. > > rob > Is it possible to search the same field for multiple values? e.g. I want to search for Bill and Ben, both of whom exist, but I get "No results found for 'Bill Ben'". -- David O'Brien RHCT PGP-KeyID: 0x443CBA7B -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From ssorce at redhat.com Fri Nov 16 16:32:05 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 16 Nov 2007 11:32:05 -0500 Subject: [Freeipa-devel] containers In-Reply-To: <473DBD7A.7010800@redhat.com> References: <473DBD7A.7010800@redhat.com> Message-ID: <1195230725.24778.12.camel@localhost.localdomain> On Fri, 2007-11-16 at 10:55 -0500, John Dennis wrote: > From reading the code in funcs.py I think we might have > collision/ambiguity problem. The code seems a bit schizophrenic about > specifying the container in which to search. In many instances a search > will just start at the suffix and makes the assumption the attribute it > is searching for is unique, that is probably not a good assumption if > you have more than one container in the tree. > > The add_{user,group}() methods take an optional container parameter but > the __is_{user,group}_unique() methods ignore it and just search from > the root. The same holds true for the get_XXX_by_XXX() methods. > > If there is more than one container in the tree we'll end up with > inconsistent results. Will we ever have more than one container for > things? Yes. For instance radius wants to have containers under > services. I'm afraid some of the root based searches could end up > finding things there instead. Whether or not this is true for specific > pieces of radius data (I have not verified this due to bad searches) it > just seems like a lurking problem and potential source of bugs, > especially as more and more data gets added to the tree and hung off of > different container nodes. > > Shouldn't the functions performing searches always specify the container > they are searching under? As long as the correct objectClasses are searched for the current behavior is correct. If we find 2 users with the same uid for example we are in trouble anyway as uid is used in client to name users, same for cn and objects with posixGroup objectClass. What kind of conflicts do you see for radius? And please can you send a little schematics of what exactly you need and why and how you would propose to add subtrees (and where) ? Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From david.obrien at redhat.com Fri Nov 16 17:13:21 2007 From: david.obrien at redhat.com (David O'Brien) Date: Sat, 17 Nov 2007 03:13:21 +1000 Subject: [Freeipa-devel] variation in cli and web functions? Message-ID: <473DCFB1.3060403@redhat.com> Just for fun, I added a user via the cli. That's fine, showed up in the webUI ok, just get a different set of defaults and mandatory fields. Then: ipa-usermod --set memberOf="Office Manager" fdaway fdaway successfully updated ipa-usermod --set memberOf=finance fdaway fdaway successfully updated But if I view that user in the webUI the groups don't display. If I list the group, that user doesn't show up. So then: ldapsearch -Y GSSAPI -b "dc=example, dc=com" uid=fdaway | grep memberOf SASL/GSSAPI authentication started SASL username: admin at EXAMPLE.COM SASL SSF: 56 SASL installing layers memberOf: finance memberOf: cn=office manager,cn=groups,cn=accounts,dc=example,dc=com What's happening there? I'm running the webUI on the server, and for the cli I'm using ssh from another machine. Running F7, 32-bit. Build is probably 3 - 4 days old. -- David O'Brien RHCT PGP-KeyID: 0x443CBA7B -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jdennis at redhat.com Fri Nov 16 18:00:00 2007 From: jdennis at redhat.com (John Dennis) Date: Fri, 16 Nov 2007 13:00:00 -0500 Subject: [Freeipa-devel] containers In-Reply-To: <1195230725.24778.12.camel@localhost.localdomain> References: <473DBD7A.7010800@redhat.com> <1195230725.24778.12.camel@localhost.localdomain> Message-ID: <473DDAA0.4030309@redhat.com> Simo Sorce wrote: > On Fri, 2007-11-16 at 10:55 -0500, John Dennis wrote: >> Shouldn't the functions performing searches always specify the container >> they are searching under? > > As long as the correct objectClasses are searched for the current > behavior is correct. But they aren't. See get_user_by_uid(), it just searches for uid=XXX. Doesn't that have the potential to return any entry with a uid attribute? I realize you're going to say "but nothing else in the tree should ever have a uid attribute". That might be hard to enforce and if it's not the uid attribute it might be some other non-unique attribute that creates a problem, just don't get too hung up on uid as the example. > If we find 2 users with the same uid for example we are in trouble > anyway as uid is used in client to name users, same for cn and objects > with posixGroup objectClass. Containers are like name spaces, without them it's like programming with a lot of global variables. > What kind of conflicts do you see for radius? I'm not sure there is a specific problem yet, it just feels like a potential problem if you don't "namespace" things. Here's where I first started to sense a problem. Radius profiles can be attached to user entries or they can live independently, in this case under the profiles container of the radius service. When the profile is attached to a user it's looked up by uid. What does it get looked up by when it's under the profiles container? There is a temptation to have it referenced by the same attribute but point the search at a different container. In this particular instance I think the correct solution is to have the profile referenced by 'cn' in the profiles container and make sure that any search will use a different attribute depending on which container it's in. That's all well and good, but it requires a certain discipline, just like using global variables, to make sure you never introduce a conflict. As more and more data gets added it might be hard to enforce that discipline and gaurantee robustness. The discipline also means certain attributes can never be used in other entries or you run the risk of a loosely specified search which starts at the root finding it. Namespaces were introduced in part to solve 'programming discipline' problems and segment data, it seems to me containers are equivalent to namespaces with many of the same issues. If you're looking for some data look for it in its namespace, not in the union of all namespaces, e.g. start the search at the appropriate container, not the root. -- John Dennis From rcritten at redhat.com Fri Nov 16 18:00:57 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 16 Nov 2007 13:00:57 -0500 Subject: [Freeipa-devel] [PATCH] Huge page that finished UI-based policies and adds password policies Message-ID: <473DDAD9.606@redhat.com> Implement the password policy UI and finish IPA policy UI This includes a default password policy Custom fields are now read from LDAP. The format is a list of dicts with keys: label, field, required. The LDAP-based configuration now specifies: ipaUserSearchFields: uid,givenName,sn,telephoneNumber,ou,title ipaGroupSearchFields: cn,description ipaSearchTimeLimit: 2 ipaSearchRecordsLimit: 0 ipaCustomFields: ipaHomesRootDir: /home ipaDefaultLoginShell: /bin/sh ipaDefaultPrimaryGroup: ipausers ipaMaxUsernameLength: 8 ipaPwdExpAdvNotify: 4 This could use some optimization but it is workable for now. This patch needs the UI storage schema that Simo is working. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-414-uipolicy.patch Type: text/x-patch Size: 52398 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 Fri Nov 16 18:06:04 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 16 Nov 2007 13:06:04 -0500 Subject: [Freeipa-devel] variation in cli and web functions? In-Reply-To: <473DCFB1.3060403@redhat.com> References: <473DCFB1.3060403@redhat.com> Message-ID: <473DDC0C.7000000@redhat.com> David O'Brien wrote: > Just for fun, I added a user via the cli. That's fine, showed up in the > webUI ok, just get a different set of defaults and mandatory fields. > > Then: > > ipa-usermod --set memberOf="Office Manager" fdaway > fdaway successfully updated > ipa-usermod --set memberOf=finance fdaway > fdaway successfully updated > > But if I view that user in the webUI the groups don't display. If I list > the group, that user doesn't show up. > > So then: > > ldapsearch -Y GSSAPI -b "dc=example, dc=com" uid=fdaway | grep memberOf > SASL/GSSAPI authentication started > SASL username: admin at EXAMPLE.COM > SASL SSF: 56 > SASL installing layers > memberOf: finance > memberOf: cn=office manager,cn=groups,cn=accounts,dc=example,dc=com > > What's happening there? > > I'm running the webUI on the server, and for the cli I'm using ssh from > another machine. > > Running F7, 32-bit. Build is probably 3 - 4 days old. memberof doesn't work this way. If you want to add a user to a group use ipa-groupmod. That said, we may want to prevent this type of thing. 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 Fri Nov 16 18:10:46 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 16 Nov 2007 13:10:46 -0500 Subject: [Freeipa-devel] containers In-Reply-To: <473DDAA0.4030309@redhat.com> References: <473DBD7A.7010800@redhat.com> <1195230725.24778.12.camel@localhost.localdomain> <473DDAA0.4030309@redhat.com> Message-ID: <1195236646.24778.21.camel@localhost.localdomain> On Fri, 2007-11-16 at 13:00 -0500, John Dennis wrote: > Simo Sorce wrote: > > On Fri, 2007-11-16 at 10:55 -0500, John Dennis wrote: > >> Shouldn't the functions performing searches always specify the container > >> they are searching under? > > > > As long as the correct objectClasses are searched for the current > > behavior is correct. > > But they aren't. See get_user_by_uid(), it just searches for uid=XXX. > Doesn't that have the potential to return any entry with a uid > attribute? I realize you're going to say "but nothing else in the tree > should ever have a uid attribute". No I am going to say this is a bug, we should *always* search with the right objectclass in the filter. > That might be hard to enforce and if > it's not the uid attribute it might be some other non-unique attribute > that creates a problem, just don't get too hung up on uid as the example. NO the bug is in not searching with the objectclass, for some reason that slipped in that way, it's a bug. > > If we find 2 users with the same uid for example we are in trouble > > anyway as uid is used in client to name users, same for cn and objects > > with posixGroup objectClass. > > Containers are like name spaces, without them it's like programming with > a lot of global variables. Yes tell it to the nsswitch guys. For some things unfortunately our world is still flat, we have to live with that. > > What kind of conflicts do you see for radius? > > I'm not sure there is a specific problem yet, it just feels like a > potential problem if you don't "namespace" things. We don't do namespace for anything user or group, simply because nsswitch can't understand that. For anything else we can. > Here's where I first started to sense a problem. Radius profiles can be > attached to user entries or they can live independently, in this case > under the profiles container of the radius service. When the profile is > attached to a user it's looked up by uid. What does it get looked up by > when it's under the profiles container? There is a temptation to have it > referenced by the same attribute but point the search at a different > container. In this particular instance I think the correct solution is > to have the profile referenced by 'cn' in the profiles container and > make sure that any search will use a different attribute depending on > which container it's in. No, as long as the othe radius stuff does not contain posixAccount you can use uid, an alternative solution is to use an attirbute unique to radius. Searching gon different attribute based on the container, simply put, is wrong on premises. > That's all well and good, but it requires a certain discipline, just > like using global variables, to make sure you never introduce a > conflict. As more and more data gets added it might be hard to enforce > that discipline and gaurantee robustness. That's not good. Discipline in LDAP is based on objectClasses not on tree structure. Anything that rely on the tree structure for generic searches is often just bad architecture. > The discipline also means certain attributes can never be used in other > entries or you run the risk of a loosely specified search which starts > at the root finding it. ObjectClasses, they are there exactly for that reason, filter what you need from what you need not. > Namespaces were introduced in part to solve 'programming discipline' > problems and segment data, it seems to me containers are equivalent to > namespaces with many of the same issues. If you're looking for some data > look for it in its namespace, not in the union of all namespaces, e.g. > start the search at the appropriate container, not the root. Ok you just got it wrong, in this context namespaces == objectClasses in LDAP, the tree is not. Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From jdennis at redhat.com Fri Nov 16 18:35:01 2007 From: jdennis at redhat.com (John Dennis) Date: Fri, 16 Nov 2007 13:35:01 -0500 Subject: [Freeipa-devel] containers In-Reply-To: <1195236646.24778.21.camel@localhost.localdomain> References: <473DBD7A.7010800@redhat.com> <1195230725.24778.12.camel@localhost.localdomain> <473DDAA0.4030309@redhat.com> <1195236646.24778.21.camel@localhost.localdomain> Message-ID: <473DE2D5.1040305@redhat.com> Simo Sorce wrote: > Ok you just got it wrong, in this context namespaces == objectClasses in > LDAP, the tree is not. Every book I've read on LDAP uses tree structure to partition data, I guess they got it wrong too :-) An objectClass is equivalent to a struct not a namespace. That's like saying all variables of type X can only be stored in the same global array. -- John Dennis From rmeggins at redhat.com Fri Nov 16 18:39:14 2007 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 16 Nov 2007 11:39:14 -0700 Subject: [Freeipa-devel] containers In-Reply-To: <473DE2D5.1040305@redhat.com> References: <473DBD7A.7010800@redhat.com> <1195230725.24778.12.camel@localhost.localdomain> <473DDAA0.4030309@redhat.com> <1195236646.24778.21.camel@localhost.localdomain> <473DE2D5.1040305@redhat.com> Message-ID: <473DE3D2.5000209@redhat.com> John Dennis wrote: > Simo Sorce wrote: >> Ok you just got it wrong, in this context namespaces == objectClasses in >> LDAP, the tree is not. > > Every book I've read on LDAP uses tree structure to partition data, I > guess they got it wrong too :-) The hierarchy came from X.500, which actually has a very rigid hierarchy that you must conform to. One of the things that makes LDAP "lightweight" is that it allows you to create your own tree structure much more easily. What we have found over several years is that it makes deployments much easier to have a flat name space and use attributes in entries to control group membership, roles, access control, etc. rather than basing all of these on which container the entry is in. However, Active Directory places a great deal of emphasis on hierarchy, using container as the default grouping mechanism, meaning entries are moved into and between containers very often, organizations may have hundreds of containers, nested containers, etc. > > An objectClass is equivalent to a struct not a namespace. That's like > saying all variables of type X can only be stored in the same global > array. > -------------- 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 prowley at redhat.com Fri Nov 16 18:50:21 2007 From: prowley at redhat.com (Pete Rowley) Date: Fri, 16 Nov 2007 10:50:21 -0800 Subject: [Freeipa-devel] search fields In-Reply-To: <473DC254.8020806@redhat.com> References: <473DB9E9.9070300@redhat.com> <473DC254.8020806@redhat.com> Message-ID: <473DE66D.6070500@redhat.com> David O'Brien wrote: > Rob Crittenden wrote: > >> I have a memory of talking about this before but can't find the e-mails. >> >> I'm working on policy configuration now and setting the default search >> fields. They are: >> >> users: uid,givenName,sn,telephoneNumber,ou,title >> groups: cn,description >> >> If you want additional fields speak now :-) >> >> I seem to recall discussing add carLicense and displayname. >> >> rob >> >> > > Is it possible to search the same field for multiple values? e.g. I want > to search for Bill and Ben, both of whom exist, but I get "No results > found for 'Bill Ben'". > > This should work - looks like a regression. -- Pete -------------- 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 prowley at redhat.com Fri Nov 16 18:52:59 2007 From: prowley at redhat.com (Pete Rowley) Date: Fri, 16 Nov 2007 10:52:59 -0800 Subject: [Freeipa-devel] search fields In-Reply-To: <473DB9E9.9070300@redhat.com> References: <473DB9E9.9070300@redhat.com> Message-ID: <473DE70B.1020606@redhat.com> Rob Crittenden wrote: > I have a memory of talking about this before but can't find the e-mails. > > I'm working on policy configuration now and setting the default search > fields. They are: > > users: uid,givenName,sn,telephoneNumber,ou,title > groups: cn,description > > If you want additional fields speak now :-) > > I seem to recall discussing add carLicense and displayname. From the display page here is the list of things NOT to search on :) initials account status home directory login shell gecos home page -- Pete -------------- 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 Nov 16 19:54:45 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 16 Nov 2007 14:54:45 -0500 Subject: [Freeipa-devel] containers In-Reply-To: <473DE2D5.1040305@redhat.com> References: <473DBD7A.7010800@redhat.com> <1195230725.24778.12.camel@localhost.localdomain> <473DDAA0.4030309@redhat.com> <1195236646.24778.21.camel@localhost.localdomain> <473DE2D5.1040305@redhat.com> Message-ID: <1195242885.24778.26.camel@localhost.localdomain> On Fri, 2007-11-16 at 13:35 -0500, John Dennis wrote: > Simo Sorce wrote: > > Ok you just got it wrong, in this context namespaces == objectClasses in > > LDAP, the tree is not. > > Every book I've read on LDAP uses tree structure to partition data, I > guess they got it wrong too :-) That's a different thing. The tree structure is used to organize data not to partition it. > An objectClass is equivalent to a struct not a namespace. That's like > saying all variables of type X can only be stored in the same global array. The analogy does not work at all so I will not try to refute it as it makes no sense to me at this level. If you want a radius object you should search for the radius objectclass in the filter. searching just for "uid" is not ok. Searching for both it is. Adding a constraint on the tree you want to search by means of a base dn is also ok. Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From kmacmillan at mentalrootkit.com Fri Nov 16 20:39:15 2007 From: kmacmillan at mentalrootkit.com (Karl MacMillan) Date: Fri, 16 Nov 2007 15:39:15 -0500 Subject: [Freeipa-devel] Release today Message-ID: <1195245555.31334.2.camel@clapton.mentalrootkit.com> We were aiming for a release today, but it doesn't look like all of the patches are going to land in time. Even if they did, I'd hesitate to shove a basically untested tree out the door. I'd like to make the release next Tue. To do that, all large, feature patches need to be pushed on Mon. We can then kick the tires and make the release on Tue. Objections? Karl From rcritten at redhat.com Fri Nov 16 23:34:56 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 16 Nov 2007 18:34:56 -0500 Subject: [Freeipa-devel] [PATCH] group inactivation Message-ID: <473E2920.2050800@redhat.com> Enable group inactivation by using the Class of Service plugin. This adds 2 new groups: activated and inactivated. If you, or a group you are a member of, is in inactivated then you are too. If you, or a group you are a member of, is in the activated group, then you are too. In a fight between activated and inactivated, activated wins. The DNs for doing this matching is case and white space sensitive. The goal is to never have to actually set nsAccountLock in a user directly but move them between these groups. We need to decide where in the CLI this will happen. Right it is split between ipa-deluser and ipa-usermod. To inactivate groups for now just add the group to inactivate or active. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-393-groupinact.patch Type: text/x-patch Size: 26956 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 prowley at redhat.com Fri Nov 16 23:47:52 2007 From: prowley at redhat.com (Pete Rowley) Date: Fri, 16 Nov 2007 15:47:52 -0800 Subject: [Freeipa-devel] [PATCH] group inactivation In-Reply-To: <473E2920.2050800@redhat.com> References: <473E2920.2050800@redhat.com> Message-ID: <473E2C28.8000607@redhat.com> Rob, some "dc=greyoak,dc=com" slipped through in the ldif where you need $SUFFIX Rob Crittenden wrote: > Enable group inactivation by using the Class of Service plugin. > > This adds 2 new groups: activated and inactivated. > > If you, or a group you are a member of, is in inactivated then you are > too. > > If you, or a group you are a member of, is in the activated group, > then you are too. > > In a fight between activated and inactivated, activated wins. > > The DNs for doing this matching is case and white space sensitive. > > The goal is to never have to actually set nsAccountLock in a user > directly but move them between these groups. > > We need to decide where in the CLI this will happen. Right it is split > between ipa-deluser and ipa-usermod. To inactivate groups for now just > add the group to inactivate or active. > > rob > ------------------------------------------------------------------------ > > # HG changeset patch > # User Rob Crittenden > # Date 1195256075 18000 > # Node ID 9d7abd059a55e0114aa02efcb061715d086690f8 > # Parent ac81ba2624815b925447ca9e70208f5ede8b973e > Enable group inactivation by using the Class of Service plugin. > > This adds 2 new groups: activated and inactivated. > > If you, or a group you are a member of, is in inactivated then you are too. > > If you, or a group you are a member of, is in the activated group, then you > are too. > > In a fight between activated and inactivated, activated wins. > > The DNs for doing this matching is case and white space sensitive. > > The goal is to never have to actually set nsAccountLock in a user directly > but move them between these groups. > > We need to decide where in the CLI this will happen. Right it is split > between ipa-deluser and ipa-usermod. To inactivate groups for now just > add the group to inactivate or active. > > diff -r ac81ba262481 -r 9d7abd059a55 ipa-admintools/ipa-deluser > --- a/ipa-admintools/ipa-deluser Thu Nov 15 12:45:44 2007 -0500 > +++ b/ipa-admintools/ipa-deluser Fri Nov 16 18:34:35 2007 -0500 > @@ -57,11 +57,14 @@ def main(): > ret = client.delete_user(args[1]) > msg = "deleted" > else: > - ret = client.mark_user_deleted(args[1]) > - if (ret == "Success"): > + try: > + ret = client.mark_user_inactive(args[1]) > + except ipa.ipaerror.exception_for(ipa.ipaerror.LDAP_EMPTY_MODLIST): > + print "User is already marked inactive" > + return 0 > + except: > + raise > print args[1] + " successfully %s" % msg > - else: > - print args[1] + " " + ret > except xmlrpclib.Fault, fault: > if fault.faultCode == errno.ECONNREFUSED: > print "The IPA XML-RPC service is not responding." > diff -r ac81ba262481 -r 9d7abd059a55 ipa-admintools/ipa-usermod > --- a/ipa-admintools/ipa-usermod Thu Nov 15 12:45:44 2007 -0500 > +++ b/ipa-admintools/ipa-usermod Fri Nov 16 18:34:35 2007 -0500 > @@ -32,7 +32,7 @@ import errno > import errno > > def usage(): > - print "ipa-usermod [-c|--gecos STRING] [-d|--directory STRING] [-f|--firstname STRING] [-l|--lastname STRING] [-s|--shell STRING] [--add attribute=value] [--del attribute] [--set attribute=value] user" > + print "ipa-usermod [-a|--activate] [-c|--gecos STRING] [-d|--directory STRING] [-f|--firstname STRING] [-l|--lastname STRING] [-s|--shell STRING] [--add attribute=value] [--del attribute] [--set attribute=value] user" > sys.exit(1) > > def set_add_usage(which): > @@ -40,6 +40,8 @@ def set_add_usage(which): > > def parse_options(): > parser = OptionParser() > + parser.add_option("-a", "--activate", dest="activate", action="store_true", > + help="Activate the user") > parser.add_option("-c", "--gecos", dest="gecos", > help="Set the GECOS field") > parser.add_option("-d", "--directory", dest="directory", > @@ -103,7 +105,7 @@ def main(): > return 1 > > # If any options are set we use just those. Otherwise ask for all of them. > - if options.gn or options.sn or options.directory or options.gecos or options.mail or options.shell or options.addattr or options.delattr or options.setattr: > + if options.gn or options.sn or options.directory or options.gecos or options.mail or options.shell or options.addattr or options.delattr or options.setattr or options.activate: > givenname = options.gn > lastname = options.sn > gecos = options.gecos > @@ -229,8 +231,16 @@ def main(): > value = cvalue + [value] > user.setValue(attr, value) > > - > try: > + if options.activate: > + try: > + client.mark_user_active(user.getValues('uid')) > + print "User activated successfully." > + except ipa.ipaerror.exception_for(ipa.ipaerror.LDAP_EMPTY_MODLIST): > + print "User is already marked active" > + return 0 > + except: > + raise > client.update_user(user) > except xmlrpclib.Fault, fault: > if fault.faultCode == errno.ECONNREFUSED: > diff -r ac81ba262481 -r 9d7abd059a55 ipa-python/ipaclient.py > --- a/ipa-python/ipaclient.py Thu Nov 15 12:45:44 2007 -0500 > +++ b/ipa-python/ipaclient.py Fri Nov 16 18:34:35 2007 -0500 > @@ -173,10 +173,16 @@ class IPAClient: > > return result > > - def mark_user_deleted(self,uid): > + def mark_user_active(self,uid): > + """Set a user as active by uid.""" > + > + result = self.transport.mark_user_active(uid) > + return result > + > + def mark_user_inactive(self,uid): > """Set a user as inactive by uid.""" > > - result = self.transport.mark_user_deleted(uid) > + result = self.transport.mark_user_inactive(uid) > return result > > # Groups support > @@ -331,3 +337,15 @@ class IPAClient: > entries.append(user.User(e)) > > return entries > + > + def mark_group_active(self,cn): > + """Set a group as active by cn.""" > + > + result = self.transport.mark_group_active(cn) > + return result > + > + def mark_group_inactive(self,cn): > + """Set a group as inactive by cn.""" > + > + result = self.transport.mark_group_inactive(cn) > + return result > diff -r ac81ba262481 -r 9d7abd059a55 ipa-python/rpcclient.py > --- a/ipa-python/rpcclient.py Thu Nov 15 12:45:44 2007 -0500 > +++ b/ipa-python/rpcclient.py Fri Nov 16 18:34:35 2007 -0500 > @@ -309,18 +309,32 @@ class RPCClient: > > return result > > - def mark_user_deleted(self,uid): > - """Mark a user as deleted/inactive""" > - server = self.setup_server() > - > - try: > - result = server.mark_user_deleted(uid) > - except xmlrpclib.Fault, fault: > - raise ipaerror.gen_exception(fault.faultCode, fault.faultString) > - except socket.error, (value, msg): > - raise xmlrpclib.Fault(value, msg) > - > - return ipautil.unwrap_binary_data(result) > + def mark_user_active(self,uid): > + """Mark a user as active""" > + server = self.setup_server() > + > + try: > + result = server.mark_user_active(uid) > + except xmlrpclib.Fault, fault: > + raise ipaerror.gen_exception(fault.faultCode, fault.faultString) > + except socket.error, (value, msg): > + raise xmlrpclib.Fault(value, msg) > + > + return ipautil.unwrap_binary_data(result) > + > + def mark_user_inactive(self,uid): > + """Mark a user as inactive""" > + server = self.setup_server() > + > + try: > + result = server.mark_user_inactive(uid) > + except xmlrpclib.Fault, fault: > + raise ipaerror.gen_exception(fault.faultCode, fault.faultString) > + except socket.error, (value, msg): > + raise xmlrpclib.Fault(value, msg) > + > + return ipautil.unwrap_binary_data(result) > + > > # Group support > > @@ -591,3 +605,29 @@ class RPCClient: > raise xmlrpclib.Fault(value, msg) > > return ipautil.unwrap_binary_data(result) > + > + def mark_group_active(self,cn): > + """Mark a group as active""" > + server = self.setup_server() > + > + try: > + result = server.mark_group_active(cn) > + except xmlrpclib.Fault, fault: > + raise ipaerror.gen_exception(fault.faultCode, fault.faultString) > + except socket.error, (value, msg): > + raise xmlrpclib.Fault(value, msg) > + > + return ipautil.unwrap_binary_data(result) > + > + def mark_group_inactive(self,cn): > + """Mark a group as inactive""" > + server = self.setup_server() > + > + try: > + result = server.mark_group_inactive(cn) > + except xmlrpclib.Fault, fault: > + raise ipaerror.gen_exception(fault.faultCode, fault.faultString) > + except socket.error, (value, msg): > + raise xmlrpclib.Fault(value, msg) > + > + return ipautil.unwrap_binary_data(result) > diff -r ac81ba262481 -r 9d7abd059a55 ipa-server/ipa-gui/ipagui/forms/group.py > --- a/ipa-server/ipa-gui/ipagui/forms/group.py Thu Nov 15 12:45:44 2007 -0500 > +++ b/ipa-server/ipa-gui/ipagui/forms/group.py Fri Nov 16 18:34:35 2007 -0500 > @@ -8,6 +8,10 @@ class GroupFields(): > description = widgets.TextField(name="description", label="Description") > > editprotected_hidden = widgets.HiddenField(name="editprotected") > + > + nsAccountLock = widgets.SingleSelectField(name="nsAccountLock", > + label="Group Status", > + options = [("", "active"), ("true", "inactive")]) > > group_orig = widgets.HiddenField(name="group_orig") > member_data = widgets.HiddenField(name="member_data") > diff -r ac81ba262481 -r 9d7abd059a55 ipa-server/ipa-gui/ipagui/subcontrollers/group.py > --- a/ipa-server/ipa-gui/ipagui/subcontrollers/group.py Thu Nov 15 12:45:44 2007 -0500 > +++ b/ipa-server/ipa-gui/ipagui/subcontrollers/group.py Fri Nov 16 18:34:35 2007 -0500 > @@ -22,7 +22,7 @@ group_new_form = ipagui.forms.group.Grou > group_new_form = ipagui.forms.group.GroupNewForm() > group_edit_form = ipagui.forms.group.GroupEditForm() > > -group_fields = ['*'] > +group_fields = ['*', 'nsAccountLock'] > > class GroupController(IPAController): > > @@ -75,6 +75,9 @@ class GroupController(IPAController): > new_group.setValue('description', kw.get('description')) > > rv = client.add_group(new_group) > + > + if kw.get('nsAccountLock'): > + client.mark_group_inactive(kw.get('cn')) > except ipaerror.exception_for(ipaerror.LDAP_DUPLICATE): > turbogears.flash("Group with name '%s' already exists" % > kw.get('cn')) > @@ -224,6 +227,12 @@ class GroupController(IPAController): > turbogears.flash("Edit group cancelled") > raise turbogears.redirect('/group/show', cn=cn[0]) > > + if kw.get('editprotected') == '': > + # if editprotected set these don't get sent in kw > + orig_group_dict = loads(b64decode(kw.get('group_orig'))) > + kw['cn'] = orig_group_dict['cn'] > + kw['gidnumber'] = orig_group_dict['gidnumber'] > + > # Decode the member data, in case we need to round trip > member_dicts = loads(b64decode(kw.get('member_data'))) > > @@ -251,6 +260,17 @@ class GroupController(IPAController): > if new_group.gidnumber != new_gid: > group_modified = True > new_group.setValue('gidnumber', new_gid) > + else: > + new_group.setValue('gidnumber', orig_group_dict.get('gidnumber')) > + new_group.setValue('cn', orig_group_dict.get('cn')) > + if new_group.cn != kw.get('cn'): > + group_modified = True > + new_group.setValue('cn', kw['cn']) > + > + if group_modified: > + rv = client.update_group(new_group) > + # > + # If the group update succeeds, but below operations fail, we > if new_group.cn != kw.get('cn'): > group_modified = True > new_group.setValue('cn', kw['cn']) > @@ -268,6 +288,17 @@ class GroupController(IPAController): > return dict(form=group_edit_form, group=kw, members=member_dicts, > tg_template='ipagui.templates.groupedit') > > + if kw.get('nsAccountLock') == '': > + kw['nsAccountLock'] = "false" > + > + modify_no_update = False > + if kw.get('nsAccountLock') == "false" and new_group.getValues('nsaccountlock') == "true": > + client.mark_group_active(kw.get('cn')) > + modify_no_update = True > + elif kw.get('nsAccountLock') == "true" and new_group.nsaccountlock != "true": > + client.mark_group_inactive(kw.get('cn')) > + modify_no_update = True > + > # > # Add members > # > @@ -326,7 +357,7 @@ class GroupController(IPAController): > cn0 = kw['cn'][0] > else: > cn0 = kw['cn'] > - if group_modified == True: > + if group_modified == True or modify_no_update == True: > turbogears.flash("%s updated!" % cn0) > else: > turbogears.flash("No modifications requested.") > diff -r ac81ba262481 -r 9d7abd059a55 ipa-server/ipa-gui/ipagui/subcontrollers/user.py > --- a/ipa-server/ipa-gui/ipagui/subcontrollers/user.py Thu Nov 15 12:45:44 2007 -0500 > +++ b/ipa-server/ipa-gui/ipagui/subcontrollers/user.py Fri Nov 16 18:34:35 2007 -0500 > @@ -174,14 +174,14 @@ class UserController(IPAController): > new_user.setValue('carlicense', kw.get('carlicense')) > new_user.setValue('labeleduri', kw.get('labeleduri')) > > - if kw.get('nsAccountLock'): > - new_user.setValue('nsAccountLock', 'true') > - > for custom_field in user_new_form.custom_fields: > new_user.setValue(custom_field.name, > kw.get(custom_field.name, '')) > > rv = client.add_user(new_user) > + > + if kw.get('nsAccountLock'): > + client.mark_user_inactive(kw.get('uid')) > except ipaerror.exception_for(ipaerror.LDAP_DUPLICATE): > turbogears.flash("Person with login '%s' already exists" % > kw.get('uid')) > @@ -458,12 +458,6 @@ class UserController(IPAController): > new_user.setValue('carlicense', kw.get('carlicense')) > new_user.setValue('labeleduri', kw.get('labeleduri')) > > - > - if kw.get('nsAccountLock'): > - new_user.setValue('nsAccountLock', 'true') > - else: > - new_user.setValue('nsAccountLock', None) > - > if kw.get('editprotected') == 'true': > if kw.get('userpassword'): > password_change = True > @@ -544,6 +538,20 @@ class UserController(IPAController): > if password_change: > message = "User password successfully updated.
" + message > turbogears.flash(message) > + return dict(form=user_edit_form, user=kw, > + user_groups=user_groups_dicts, > + tg_template='ipagui.templates.useredit') > + > + if kw.get('nsAccountLock') == '': > + kw['nsAccountLock'] = "false" > + > + try: > + if kw.get('nsAccountLock') == "false" and new_user.getValues('nsaccountlock') == "true": > + client.mark_user_active(kw.get('uid')) > + elif kw.get('nsAccountLock') == "true" and new_user.nsaccountlock != "true": > + client.mark_user_inactive(kw.get('uid')) > + except ipaerror.IPAError, e: > + turbogears.flash("User status change failed: " + str(e) + "
" + e.detail[0]['desc']) > return dict(form=user_edit_form, user=kw, > user_groups=user_groups_dicts, > tg_template='ipagui.templates.useredit') > diff -r ac81ba262481 -r 9d7abd059a55 ipa-server/ipa-gui/ipagui/templates/groupeditform.kid > --- a/ipa-server/ipa-gui/ipagui/templates/groupeditform.kid Thu Nov 15 12:45:44 2007 -0500 > +++ b/ipa-server/ipa-gui/ipagui/templates/groupeditform.kid Fri Nov 16 18:34:35 2007 -0500 > @@ -112,6 +112,16 @@ from ipagui.helpers import ipahelper > > > > + > + > +