Nathan Kinder wrote:
I think they use ldif files that they either pass to ldapmodify or parse with python-ldap. I think it would be useful to do that too, and possibly provide hooks that ipa could use. So we can have 3 types of files to execute during upgrade perl code - small perl scripts, which can be imported into the setup perl interpreter and executed in that contextOn 09/01/2009 03:38 PM, Rich Megginson wrote:That makes sense. We may want to talk with Rob C. since I think he's done something similar for FreeIPA's upgrade procedure with regards to DS plug-in config. Perhaps he has some insight.Nathan Kinder wrote:Sort of, but much smaller. And not necessarily version specific - see below.On 09/01/2009 02:23 PM, Rich Megginson wrote:I'm envisioning something like patch files in an RPM - things that can easily come and go depending on what needs to be done for a particular release. In this case, instead of patch files, these would be short perl or shell scripts. These would be invoked once or once per instance.One way would be to have a large script which would be edited for each release, adding or deleting code as needed. This is the way it worked in the past - the file quickly becomes "unruly". However, we would only have to touch Makefile.am once to add the upgrade script.You mean like the migrate4to6, migrate5to6, etc. stuff?I'm hoping to avoid looking at explicit versions. Instead, I would prefer that the scriptlet would determine if the work it needed to do is already done. For example, upgrading from 1.2.0 to 1.2.x would need to add the syntax validation plugin. The scriptlet should check to see if the syntax validation plugin exists before adding it. I can't really think of anything which would require an explicit version.Another way would be to have small scripts that could come and go with each release. The disadvantage is that we would be constantly adding/deleting items from Makefile.am. This is what I would prefer.I prefer the scriptlet approach too.How do you envision dealing with upgrading from different versions? For example, we would need to do much different work upgrading from 1.1 -> 1.3 than we would from 1.2 -> 1.3. Will there be some way for the scriptlet to specify what versions it needs to be run for?
ldif - which can be applied by the use of our current ldif code in setupexecutable code - which will primarily be shell scripts, but I don't think there is any reason to limit it - we will need some way to pass the context to them, probably in the form of environment variables (INSTANCEDIR=/etc/dirsrv/slapd-foo ; BINDDN="cn=directory manager"; BINDPW="password" ; etc.)
I think there will have to some sort of manifest file (or main controlling script) to control the order of execution of these upgrade scripts/ldif. Either that, or some sort of scheme like we use for schema files - name the files 00something through 99something and have them executed in order. The numbering scheme might be tricky to manage. The manifest/upgrade script will probably get ugly after a while.
Before invoking the update scripts, the code would create some sort of context, containing information about the config directory, each instance, and an identity and credentials that can be used to manage each instance. For example, when you run setup-ds-admin.pl -u, it uses the uid=admin identity and asks for the password, then uses that identity to manage each instance. However, in the case where there is just the base ds package, we would need some way to ask or specify the identity for each instance. For the UI, I don't think there's any way around just simply asking for the username and password for each instance (we can default the username to directory manager or the last value specified). For .inf file usage, I was thinking about adding a new section - [slapd-instancename] - in which you could specify the RootDN and RootDNPwd. -------------------------------------------------------------------------- 389-devel mailing list 389-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-devel-------------------------------------------------------------------------- 389-devel mailing list 389-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-devel------------------------------------------------------------------------ -- 389-devel mailing list 389-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-devel------------------------------------------------------------------------ -- 389-devel mailing list 389-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-devel
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- 389-devel mailing list 389-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-devel
