Clarity of iMS 5.2 Migration Guide
Hi all, I have been running through the steps to upgrade our NMS 4.1.5 single server instance to iMS 5.2 on Solaris. I have found the steps in the document to be very vague in a lot of places and would like to post my experiences here (from a customers perspective) to aid people in the future and perhaps obtain some feedback. The steps I have been following are from Chapter 3 Migrating from a Single-Server NMS System.
The perquisite of Directory Server 4.12 was kind of confusing to me since I installed NMS and it came with 4.1. Anyhow, this upgrade is simple and straightforward.
In Step 2 you are required to turn on multi schema support. I have found that you need to include the merged conf files after the initial includes otherwise you will get various errors when you start the directory. There is an error I got that wouldnt go away after this step:
ns-pab-schema.conf: line 30: Objectclass "pabperson" contains unknown allowed attribute "mailalternateaddress"
- This objectclass uses attributes which have not been defined in your schema. The Directory Server will automatically add undefined attributes to the schema with type cis. Please define these attributes by placing their definitions before any objectclasses which use them.
Although the guide instructs you to add the merged conf files in step 2 it does not tell you if you should remove them in Step 18. Disable multi-schema support. I guess it could be implied but I am the kind of person that likes software documentation to be precise.
Step 10/12, OK now we have two messaging and directory servers installed and the manual is still using terms like instance_root.I went ahead and ran these commands on both sides; I am oblivious on what was intended here but they seemed to do something on each instance.
Silly me thought that the migration would actually move the data from the 4.12 directory to the brand new 4.16 instance so I was astonished when I realized that I now have to manage two directory servers after going to the new release; this does not seem like an elegant way to run an application but that might be subject for another thread on how to combine the two.
So now after everything is running (Webmail is so much better now) I try to find out where all the test email I am sending is going. I have had no previous experience with SIMS so the new MTA made absolutely no sense to me at first, especially since it does not log anything by default ! The new MTA seems to be a spin on sendmail in a lot of ways so I think it will be a lot more flexible and robust.
Hope this information can help someone.
Mark
Hello,
It is really aggravating that sun does not provide a way to migrate these this server without having to keep the existing 4.x server for configuration data. My own solution was to export the data from the 4.x server, import it into a dummy 4.x server on another machine, run ims_dirmigrate and imsdaaci utilities on that instance. Then export the ldif, run a replace on your base dn to replace o=<yourdomain.com> with new schema o=<yourdomain.com>,o=isp. Once this is done you can install 5.x directory and 5.x messaging and import the converted ldif file.
The server will run with all of your users intact and will also work with the schema the ida is looking for.
Performing these steps without downtime and with a backout are easier on unix since you can install the new 5.x instances in a new directory root without a problem. Just use different ports so that you can bind, then change the ports once everything is working.
On NT this is not the case. The registry gets corrupted, mixing up info from the two servers. You need to use another machine for zero downtime.
Have Fun!!!
Sorry but our MTA in iMS is nothing like Sendmail. I've used both and while I do now work for Sun, I used to be a customer who used PMDF from Innosoft. Trust me this MTA is more powerful than Sendmail.This MTA uses counted strings so there will never be a buffer overflow problem with this MTA, unlike Sendmail. ;-)
I have only skimmed the migration guide but I have heard from other customers that the migration guide is confusing. You need to read the release notes as well, important updates contained therein.
Its probably my understanding of how all this integrates together but I have helped two customers perform a migration from NMS 4.x to iMS 5.1|2 and did not have any major problems.
Depending on just how the migration of your provisioning process occurs I too fail to see why the migration guide has you turn on schema support for NMS in iMS. But alas it should not hurt anything either.
Recently I worked with a customer who was running ims_dssetup.pl against their user/group LDAP but was not updating the schema. Bad idea! You do need to update the schema of your user/group tree, as well as config and PAB if they separate from the user/group DIT.
Your directory server should be at least 4.16! Previous versions have a rather serious memory leak and will crash when they run out of memory. Depending upon how much activity your LDAP servers see will affect how long they are able to run w/o a problem. Upgrading say 4.12 to 4.16 is easy. It is a binary in place upgrade and very easy to do. Of course making a backup of your existing bits is always a good idea.
Heh, im not sure what I was talking about when I mentioned sendmail, probably just that the configuration files look so messy.
> Recently I worked with a customer who was running
> ims_dssetup.pl against their user/group LDAP but was
> not updating the schema. Bad idea! You do need to
> update the schema of your user/group tree, as well as
> config and PAB if they separate from the user/group
> DIT.
That is an interesting statement; seems to conflict with the guide though:
Step 3: Run perl ims_dssetup.pl against the Netscape Messaging Server LDAP server, and chose NOT to update the schema.
I would be interested to know the right procedure though.
>
> Your directory server should be at least 4.16!
> Previous versions have a rather serious memory leak
> and will crash when they run out of memory.
We have been using NMS 415 with DS 4.1 under a fairly heavy load for the past 2 years and there has never been a problem with the directory server. However, this DS has only been supporting the mail instance/address book. Hah, now I am worried that 4.12 is going to be problematic.
Mark
With the customer I mentioned I ran into problems like adding mailequivalientaddress to a user object because it was not defined in the schema.I did the test migration again but this time let ims_dssetup.pl update the schema (the default answer is "yes" when you run the program) and low and behold the necessary schema had been included and thus I was able to add the attribute to a user object.
I do not know of any reasons not to update the schema. Maybe it has something to do with having multiple NMS servers and thus if you've got a mixed environment of iMS and NMS, NMS would be confused if the iMS schema was introduced. Just a guess.
My experience leads me to believe updating the schema is the right answer. If I remember I'll ask internally and see if anyone disagrees with me. If I'm right then I'll try and get the MG updated. Probably help if I read the section first to get the complete picture. ;-)
As for directory and the leak. iMS brings it out more than NMS. If you configure iMS to use dirsync (the default) instead of direct LDAP lookup then you'll see it.NMS does a direct lookup for every rcpt to, the problem with that logic is a DDOS attack waiting to happen.In iMS 5.2 we've introduced a direct LDAP lookup _but_ it has an in memory cache and related TTL settings. This allows you to configure it and thus prevent a DDOS attack against your LDAP consumers.
The default of dirsync causes iMS to ask LDAP for information every 10 minutes (default) and the size of those queries are different from run to run, based on the rate of change of your LDAP data. The memory manager used in NsDS had a problem where it would not release this memory, instead keeping in cache to use again for a query of the exact same size. Given enough unique sized queries and NsDS would run out of memory.
Given how NMS worked I can see how you would not see this problem. Given how iMS 5.0/1/2 works out of the box you would see this problem in short time, in changing environments.
If you're just deploying iMS better to use direct LDAP mode anyway. It is a performance improvement as well, single digit gains, but faster is faster.I believe in the next major release of iMS or SunONE MS (or what ever it is called in the future) the dirsync mode of operation will be going away.It has been a source of trouble for us and are very happy to see it go.
Also looking to upgrade NMS415 and NMD4.16 to newer version iMS 5.2 and iDS5.1and migration notes are confusing.As you have mentioned you have done, can we know the procedure / steps you have done it.
Hello Chad,I have been trying a lot to migrate from NMS 4.15 to 5.2 but i get lot of error i even read the release note. Can u help me.RgdsDarshan
Hello,
I just want to say, that i agree with your explanation, i am very sorry that Sun can not help their customers in a so critic aspect of a software instalation - Migration procedures.
I tried to migrate from NMS4.15p7 to IMS5.2, but a could not finish it with success. The guide provided by Sun is so confusing and long, and i can not understand why? I hope they provide a more comprehensive and simple guide to migrate from NMS4.x to IMS5.x.
Azim
