Highlighted
Absent Member.
Absent Member.

Re: Migrate NetWare V6.5 to OES2 Linux SP1

Ran out of diskspace. Very important! Be sure to monitor the .Trash-root folder and log in as the person who deleted the files. The Ri/Di attributes get set on the files and do not allow the standard rm -r command. to clean up the folder.

Also, purge the volumes to keep in orderly.
0 Likes
Highlighted
Absent Member.
Absent Member.

Re: Migrate NetWare V6.5 to OES2 Linux SP1

Woohoo!!!!!!! Finally got the files migrated!

The migration had died due to disk space issues while in the middle of migrating Tomcat (not that this folder is important - it's not, but in order to test this fully, I elected to capture as many files/folders as possible, like you see in the NetWare Migration Wizard). To resolve this, I first deleted/purged out the .Trash-root folders I created unknowingly with my multitude of attempts at trying to migrate other stuff. I then tried again, but got stuck on Tomcat. I removed the existing target Tomcat directory (but not the session files) and tried again - nope! I then backed out Tomcat from the selection list, saved the project, exited the migration utility, confirmed that Tomcat was not present on the Target volume, removed the session files, and then went back in. That got it done! So now, after taking several Ibuprofen and using lots of gauze to repair my exploded head, I'm ready to start in on the sync feature.
0 Likes
Highlighted
Absent Member.
Absent Member.

Re: Migrate NetWare V6.5 to OES2 Linux SP1

Okay:

69. Once the migration of the services has completed, the Start button will transform into "Transfer Id". You have the option of clicking this button, or clicking on one of the two buttons below the services matrix: Sync & Summary.

Summary will give you a break down on where source folders were migrated to which target folders on the Linux box. This is a good place to check your progress before committing to the Transfer Id process (I would think).

Sync will start the synchronization process between the source and target. I read somewhere that this is supposed to double check for file changes between the source and the target and update those files.

If the migration process has taken some time and there is potential for deltas to exist between the source and target, click on Sync to fetch the changed files.

*** Caution! ***: This process may take a while...
0 Likes
Highlighted
Absent Member.
Absent Member.

Re: Migrate NetWare V6.5 to OES2 Linux SP1

70. If you elected the sync function, you waited patiently for it to complete. At this point, we are ready to transfer the Id of the system. Click on Transfer Id.

So far things are fairly well matching up to the documentation:

Novell Documentation

71. A warning window will appear to remind you that you are about to cross the Rubicon and to ask you are you sure you're ready. If you are, click yes. There's no turning back after this...

72. A Server Id swap window will appear. There does not appear to be any substantial options to choose here except for help, ignore (don't know what this does yet), back (currently greyed out), next and cancel. The associated help file is very informative and highly recommended reading. The ignore button allows you to ignore the current task and move onto the next one. I haven't an idea why I'd want to do that yet. Let's proceed with "Next".

73. eDirectory health check is performed. In my case, it complained that iMonitor is not loaded on my source server. I'm not sure that this is a problem just yet as it simply says "Warning". I'm continuing. Click Next.

74. The DIB will be copied from the source server. NDS is shut down on the source server. The database was closed and the log showed that the backup was successfully copied to the target. I must now manually shut down the source server.

75. Type Down at the source server console. Ensure the server has completed shut down before proceeding. I powered mine off once it reached the DOS prompt.

76. Once the source server is shut down, click Next on the target server.

77. A warning window will appear asking you to confirm that the source server is down. Proceed when you are ready and click OK.

78. The DIB will now be restored onto the target server. Click Next.

79. Once the DIB is restored, the migration will change the IP address of the target to that of the source. Click Next to continue.

80. Another Warning message will appear. This one talks about running this whole process through an SSH session and how bad that could be. If you are, now's a good time to kill it and do this from the server itself. Otherwise, click OK.

81. The Host name is next to be migrated. Click Next to continue.

That process was quick.

82. At this point the server must be restarted. The restart must be done manually. Amazingly, I was able to click on Computer, Shutdown, and was prompted to either shut the server down or restart it, which it actually executed. Nice!

Be sure to remove any CD's, DVD's etc., that may interrupt the reboot!

83. Login to the server again as root.

84. Launch the Migration Utility and reopen the job associated with the migration.

85. You will be prompted to re-authenticate to the target server. The source server icon is automatically greyed out. Click OK.

86. Click on the Target server icon.

87. The Authentication window will appear. Enter in the appropriate information and click OK.

88. The Server ID Swap window will appear. A warning window will appear asking if the server's been restarted. Click OK.

89. A "Repair" session must now be executed. It will repair eDirectory, certificates, LUM and other services. Click Next to continue.

Gotta put the little one to bed. Be back...
0 Likes
Highlighted
Absent Member.
Absent Member.

Re: Migrate NetWare V6.5 to OES2 Linux SP1

On the Repair portion of the migration swap, I see a red-circle icon (the one with the horizontal white line in the middle, sorry, brain shutting down, getting late) next to Repair, but I also get green check marks next to all of the sub-items under Repair, particularly eDirectory, Certificate, LUM and services, which make me think that we may be okay. The message log displays netstorage failures regarding restarts. At the top of the window, it displays the message, "This task was not completed. See log for more information." The Next button is greyed out, so it doesn't appear as though I can proceed. The Ignore button is looking pretty tempting right now......
0 Likes
Highlighted
Absent Member.
Absent Member.

Re: Migrate NetWare V6.5 to OES2 Linux SP1

90. Conditional: Press Ignore if it appears as though the Repair has run on all important areas listed in the left column and yet the Next button is greyed out (See previous entry for details).

This turns all of the green checkmarks under repair to oriange exclamation points. I'd like to assume that the repairs are still in effect, and that we are simply skipping to the next step, which is to manually restart the server.

91. Restart the server.

92. Login and test. At this point the "body snatching" should be complete. If there are features/applications not yet installed on the server that need to be installed, install them now and test them out.

I'll test this guy out and let you know how it looks...
0 Likes
Highlighted
Absent Member.
Absent Member.

Re: Migrate NetWare V6.5 to OES2 Linux SP1

ElliottRScott wrote:
> On the Repair portion of the migration swap, I see a red-circle icon
> (the one with the horizontal white line in the middle, sorry, brain
> shutting down, getting late) next to Repair, but I also get green check
> marks next to all of the sub-items under Repair, particularly
> eDirectory, Certificate, LUM and services, which make me think that we
> may be okay. The message log displays netstorage failures regarding
> restarts. At the top of the window, it displays the message, "This task
> was not completed. See log for more information." The Next button is
> greyed out, so it doesn't appear as though I can proceed. The Ignore
> button is looking pretty tempting right now......
>
>


Elliot,
Yes, it looks like the repair has succeeded. Can you send us the logs,
it will help us figure out why the Repair has the Red Circle Icon (Error
icon) whereas all the sub tasks are done.

Correct to do a Ignore.

Thanks & Regards
Uma
0 Likes
Absent Member.
Absent Member.

Re: Migrate NetWare V6.5 to OES2 Linux SP1

ElliottRScott;1674115 wrote:
The file system part of the migration failed. It didn't like the "- -homedir" value, saying that the path specified was neither NSS nor NCP. So, that tells me that setting the Home directory path to /home is wrong and that my initial assumption for the purpose of this field is also wrong. I'm going to reset it to something like /media/nss/vol1/users, or where ever my edir. user home directories are. Let's try that.


home dir path is for the eDirectory users home dir. If the volume that is getting migrated has the home directories for users, you need to specify the location of the new home dir. This path needs to either NSS or NCP volume. This can not be a normal posix path.

rgds
Praveen

0 Likes
Highlighted
Absent Member.
Absent Member.

Re: Migrate NetWare V6.5 to OES2 Linux SP1

sumadevi;1675724 wrote:
ElliottRScott wrote:
> On the Repair portion of the migration swap, I see a red-circle icon
> (the one with the horizontal white line in the middle, sorry, brain
> shutting down, getting late) next to Repair, but I also get green check
> marks next to all of the sub-items under Repair, particularly
> eDirectory, Certificate, LUM and services, which make me think that we
> may be okay. The message log displays netstorage failures regarding
> restarts. At the top of the window, it displays the message, "This task
> was not completed. See log for more information." The Next button is
> greyed out, so it doesn't appear as though I can proceed. The Ignore
> button is looking pretty tempting right now......
>
>


Elliot,
Yes, it looks like the repair has succeeded. Can you send us the logs,
it will help us figure out why the Repair has the Red Circle Icon (Error
icon) whereas all the sub tasks are done.

Correct to do a Ignore.

Thanks & Regards
Uma


Here are my observations post-migration:

I was able to authenticate to the OES 2 box from my Windows workstation. The NSS volumes are not available from the "My Network Places" window. I double-checked the media folder and the NSS volumes are physically present on the server. I tried to verify the mount status of the volumes via NRM, but I couldn't login via eDirectory. This tells me that there is an issue with LUM.

Once authenticated to NRM via root, I found that the only volume mounted was SYS. Under NWHealth, novell-nss is running. The following services are not running:

Apache2
novell-tomcat5
novell-xregd
novell-xsrvd
namcd

Obviously, iManager is not running. From ConsoleOne, I cannot find the LUM Workstation object. The LUM user objects that I'm hoping to see are in the server's context, but I have a feeling that they are there from when my premigration server resided there.

At this point, I believe I will need to reconfigure/reinstall LUM on the server to create the workstation object and configure the environment. I'm going to tackle that first and then review more. NSS may likely be the next item on the list.

I'll e-mail the logs from the migration to you guys as well.
0 Likes
Highlighted
Absent Member.
Absent Member.

Re: Migrate NetWare V6.5 to OES2 Linux SP1

The LUM reconfiguration recreated the workstation object and I see that, after a restart, that the NSS volumes are up again. I can also see them from my Windows workstation.

NRM shows that Apache2 and novell-tomcat5 are still not yet running. xregd also is not yet running. Looking at the admingroup, my "admin" user is the only one in there right now. I'll address that and restart again.
0 Likes
Highlighted
Absent Member.
Absent Member.

Re: Migrate NetWare V6.5 to OES2 Linux SP1

I added www and novlxtier as LUM-enabled groups and restarted the server. Apache, Tomcat and the other Novell daemons I listed are now all running.
0 Likes
Highlighted
Absent Member.
Absent Member.

Re: Migrate NetWare V6.5 to OES2 Linux SP1

I reviewed the trustee assignments against what I captured using TRUSTEE.NLM on my NetWare 6.5 box and I'm happy to report that the trustee assignments were successfully migrated to the target server. Everything there looks good.

Points to be aware of:

It makes sense that you will have to LUM-enable your users after the migration has completed. I can't expect that users will be able to up and login like nothing's changed after the migration's completed, unless I perform this step. It would be a good idea to prepare your user objects for LUM prior to starting the migration, for example, by creating a group or set of groups that you could LUM enable like I did as part of that the last entry I just made. In this way, the group object(s) would immediately accelerate the post-migration process by taking out the whole worry about things like, "did I get everybody?" Just a thought . . . That might not be a bad idea to recommend in the documentation, don't you think?

Also, depending on how your pre-migration server is set up, and I think I talked about this earlier, you may have to worry about login scripts when it comes to references to the SYS volume. In my case, I had a bunch of stuff in my public folder, e.g. client installation kits, etc., that I didn't want to lose, so I migrated the public folder to SYS_MIG, not SYS, because I felt that I had to migrate from NSS to NSS - I could be wrong on this, and please, anybody, feel free to jump in here and comment - and I know that a SYS volume (NCP Share @ /usr/novell/sys) already exists, but is not NSS-based. So, I went into this knowing I would have to make some changes there. Now I could have done some pre-migration work and redone the scripts using Novell Directory Map objects instead, which would not have been a bad idea, but I also recognize that I could only do that in certain areas. I know, I can always relocate the folders onto the original SYS volume, too, which, thankfully, is no longer hampered in terms of available space from stuff like the SYSTEM folder and others particular to NetWare, but now I'm creating more work for myself, which I'd like to avoid.

In this particular migration, iPrint/NDPS was not a factor, but I know I'll have situations where it will be, and in some environments, end-users are still relying on NDS print queues. That should be a fun experiment. I foresee a lot of double-checking of NDS objects and where they're pointing to, and maybe, some minor surgery.

I'm not complaining! This was far better than I originally anticipated. I certainly need to follow up on the points I've mentioned here. I'll let you know how it goes.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.