Re: [Freeipa-devel] [PATCH] Use File parameter for CSR in cert_request command plugin.
On Fri, 2009-11-06 at 11:47 +0100, Pavel Zuna wrote: > Makes use of the new File parameter introduced in my previous patch. > > Pavel ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Add 'File' parameter type.
On Fri, 2009-11-06 at 11:46 +0100, Pavel Zuna wrote: > Accepts filenames and loads file contents as parameter value. > > In CLI, the 'stdin_if_missing' kwarg can be used to read the file from stdin > if > no filename has been entered. > > Pavel ack. pushed to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Thoughts on client configuration
Simo Sorce wrote: On Mon, 2009-11-09 at 11:27 -0500, Rob Crittenden wrote: I've got all the pieces together to create a host principal and keytab when a machine joins an IPA realm and am thinking about how I'm going to tie it altogether. My plan revolves around enhancing ipa-client-install to call ipa-join and ipa-rmkeytab (for uninstall). The question then becomes, is the client configuration dependent upon successful machine join? We have a bit of a chicken and egg problem right now with join in terms of validating argument inputs. Joining a machine can happen one of two ways, using kerberos credentials (an admin) or using a one-time password (OTP). The OTP method is easy enough, we can call that really early in the client configuration process. If it fails (wrong password, host not created, whatever) we can simply quit and not configure the client at all. With the admin method we have to first configure the machine, then get the credentials, then try to do the join. It could easily fail here for a number of reasons. Do we roll back the configuration upon failure? Uhmm you can do admin stuff w/o necessarily configuring the machine first, for the kerberos part we can set temporary environment variables and get the admin password through a prompt. If all is successful we save the configuration in the real krb5.conf and all. Wow, fantastic idea. I actually would really prefer to do it this way so that we do not touch permanent configuration files until the join procedure is successful. Right, that's what I was afraid of. Having to fire up install machine only to then back it all out. I'm thinking the answer should be yes, otherwise some machines will have host service principals and some won't making a support nightmare. But should we have a --force option to let the client be configured anyway, in sort of a degraded mode? Or a --no-keytab option to be more explicit? Or both? Good question, in what case would it make sense to run ipa-client-install and not get the machine enrolled in ? I think that some desktop machines perhaps. Then again it is fairly trivial to manually configure the pam stack to do LDAP/kerberos. There actually already is a --force option but it applies to the DNS discovery failing. I'm all for flexibility, just not sure what the implications of this are other than support headaches like "I can log into machine A but not machine B, why not?" Well, you're missing the host keytab for some reason... Yeah, I think we should avoid half configured machines. If someone has special needs he can script his own installation procedure the way he wants, IMO. That or we need to write a very good FAQ :-) rob smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Thoughts on client configuration
On Mon, 2009-11-09 at 11:27 -0500, Rob Crittenden wrote: > I've got all the pieces together to create a host principal and keytab > when a machine joins an IPA realm and am thinking about how I'm going to > tie it altogether. > > My plan revolves around enhancing ipa-client-install to call ipa-join > and ipa-rmkeytab (for uninstall). The question then becomes, is the > client configuration dependent upon successful machine join? > > We have a bit of a chicken and egg problem right now with join in terms > of validating argument inputs. Joining a machine can happen one of two > ways, using kerberos credentials (an admin) or using a one-time password > (OTP). > > The OTP method is easy enough, we can call that really early in the > client configuration process. If it fails (wrong password, host not > created, whatever) we can simply quit and not configure the client at all. > > With the admin method we have to first configure the machine, then get > the credentials, then try to do the join. It could easily fail here for > a number of reasons. Do we roll back the configuration upon failure? Uhmm you can do admin stuff w/o necessarily configuring the machine first, for the kerberos part we can set temporary environment variables and get the admin password through a prompt. If all is successful we save the configuration in the real krb5.conf and all. I actually would really prefer to do it this way so that we do not touch permanent configuration files until the join procedure is successful. > I'm thinking the answer should be yes, otherwise some machines will have > host service principals and some won't making a support nightmare. But > should we have a --force option to let the client be configured anyway, > in sort of a degraded mode? Or a --no-keytab option to be more explicit? > Or both? Good question, in what case would it make sense to run ipa-client-install and not get the machine enrolled in ? > I'm all for flexibility, just not sure what the implications of this are > other than support headaches like "I can log into machine A but not > machine B, why not?" Well, you're missing the host keytab for some reason... Yeah, I think we should avoid half configured machines. If someone has special needs he can script his own installation procedure the way he wants, IMO. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Thoughts on client configuration
Rob Crittenden wrote: > I've got all the pieces together to create a host principal and keytab > when a machine joins an IPA realm and am thinking about how I'm going > to tie it altogether. > > My plan revolves around enhancing ipa-client-install to call ipa-join > and ipa-rmkeytab (for uninstall). The question then becomes, is the > client configuration dependent upon successful machine join? > > We have a bit of a chicken and egg problem right now with join in > terms of validating argument inputs. Joining a machine can happen one > of two ways, using kerberos credentials (an admin) or using a one-time > password (OTP). > > The OTP method is easy enough, we can call that really early in the > client configuration process. If it fails (wrong password, host not > created, whatever) we can simply quit and not configure the client at > all. > > With the admin method we have to first configure the machine, then get > the credentials, then try to do the join. It could easily fail here > for a number of reasons. Do we roll back the configuration upon failure? Why do you need first configure the machine? Why the sequence of operations is different in the OTP vs admin case. Can we have the same sequence? Then the difference is the authenticated entity and its permissions only. > > I'm thinking the answer should be yes, otherwise some machines will > have host service principals and some won't making a support > nightmare. But should we have a --force option to let the client be > configured anyway, in sort of a degraded mode? Or a --no-keytab option > to be more explicit? Or both? > > I'm all for flexibility, just not sure what the implications of this > are other than support headaches like "I can log into machine A but > not machine B, why not?" Well, you're missing the host keytab for some > reason... > > rob > > > ___ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Thoughts on client configuration
I've got all the pieces together to create a host principal and keytab when a machine joins an IPA realm and am thinking about how I'm going to tie it altogether. My plan revolves around enhancing ipa-client-install to call ipa-join and ipa-rmkeytab (for uninstall). The question then becomes, is the client configuration dependent upon successful machine join? We have a bit of a chicken and egg problem right now with join in terms of validating argument inputs. Joining a machine can happen one of two ways, using kerberos credentials (an admin) or using a one-time password (OTP). The OTP method is easy enough, we can call that really early in the client configuration process. If it fails (wrong password, host not created, whatever) we can simply quit and not configure the client at all. With the admin method we have to first configure the machine, then get the credentials, then try to do the join. It could easily fail here for a number of reasons. Do we roll back the configuration upon failure? I'm thinking the answer should be yes, otherwise some machines will have host service principals and some won't making a support nightmare. But should we have a --force option to let the client be configured anyway, in sort of a degraded mode? Or a --no-keytab option to be more explicit? Or both? I'm all for flexibility, just not sure what the implications of this are other than support headaches like "I can log into machine A but not machine B, why not?" Well, you're missing the host keytab for some reason... rob smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNS schema
Martin Nagy wrote: > On Thu, 2009-11-05 at 18:16 -0500, Dmitri Pal wrote: > >> Simo Sorce wrote: >> >>> On Thu, 2009-11-05 at 14:37 -0500, Dmitri Pal wrote: >>> >>> Hi, Now when we decided to use latest DS that is available from 389 project for IPA v2 we can take advantage of the syntaxes that DS team has added. For example they added numeric syntax that was a part of the original DNS schema we planned for IPA. I remember we replaced the originally planned syntax with some other syntax that is available. Does it make sense to revert to the numeric syntax now or it is not a big deal? I am just concerned that once we will decide to do it the original way because we would think it is the "right" thing to do and will face all sorts of migration issues. Ideas? >>> Unless it is a major amount of work we should use the proper syntax. >>> Especially for "standard" schema. >>> >>> Simo. >>> >>> >>> >> It should not be a big deal IMO so Martin if you are ok with this I >> would like to ask Pavel >> to take it as an action item. >> > > Dmitri, > I'm doing something "in the neighborhood" right now, so let me take care > of it, it'll only take little time. > > Martin > > Works for me, thanks! -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] Add BIND pre-op for DS->IPA password migration to ipa-pwd-extop DS plugin.
Re-post from ipa-and-samba-team-list. This patch makes DS generate new Kerberos keys for eligible users upon a successful simple bind. We need this for password migration. Pavel 0001-Add-BIND-pre-op-for-DS-IPA-password-migration-to-ip.patch Description: application/mbox ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNS schema
On Thu, 2009-11-05 at 18:16 -0500, Dmitri Pal wrote: > Simo Sorce wrote: > > On Thu, 2009-11-05 at 14:37 -0500, Dmitri Pal wrote: > > > >> Hi, > >> > >> Now when we decided to use latest DS that is available from 389 project > >> for IPA v2 we can take advantage of the syntaxes that DS team has added. > >> For example they added numeric syntax that was a part of the original > >> DNS schema we planned for IPA. > >> I remember we replaced the originally planned syntax with some other > >> syntax that is available. > >> > >> Does it make sense to revert to the numeric syntax now or it is not a > >> big deal? > >> I am just concerned that once we will decide to do it the original way > >> because we would think it is the "right" thing to do and will face all > >> sorts of migration issues. > >> Ideas? > >> > > > > Unless it is a major amount of work we should use the proper syntax. > > Especially for "standard" schema. > > > > Simo. > > > > > It should not be a big deal IMO so Martin if you are ok with this I > would like to ask Pavel > to take it as an action item. Dmitri, I'm doing something "in the neighborhood" right now, so let me take care of it, it'll only take little time. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
