AppNote: Moving Custom Plug-ins to iManager 2.5
Novell Cool Solutions: AppNote
By Mark Hinckley
Digg This -
Posted: 27 Jul 2005
One of the nice features of iManager 2.0.2 is the ability to create your own custom plug-ins to handle specific management tasks. However, upgrading a custom plug-in has been a bit of a worry spot for many people. This article discusses how to get custom plug-ins created with Plug-in Studio in iManager 2.0.2 moved to a server running iManager 2.5.
There are at least three different scenarios for this situation.
Scenario 1: Upgrading the existing server, using the same RBS Collection
This is actually very straightforward. There is nothing special you need to do to handle custom plug-ins in this case. Just upgrading - probably first the server, if NetWare, and then iManager from 2.0.2 to 2.5 - will be sufficient, and your custom plug-ins will be just fine. The thing to remember in upgrading iManager 2.0.2 to 2.5 is to rename or delete any maintenance update NPM files from the \webapps\nps\packages directory, because they interfere with the upgrade process. This is unrelated to any custom plug-ins you might have.
Scenario 2: Getting iManager 2.5 running on a new server in the same tree, sharing the same RBS Collection
This scenario is a bit more work. The steps for doing this are described below.
Scenario 3: New iManager 2.5 server is in a different tree, or not sharing the same RBS collection
The third scenario is similar, even if it is the same tree. Note that this process has only been tested with plug-ins created by Plug-in Studio. If you have custom plug-ins created some other way, you probably already know how to transfer them to wherever you want them.
iManager plug-ins are stored locally on each server where iManager is installed, so an eDirectory tree with several servers running iManager could have different plug-ins loaded on each server. The plug-in design of iManager does not have a mechanism to synchronize plug-ins between servers, even if they are sharing the same RBS Collection. This requires that a given plug-in be manually installed on every server where you want its functionality available. It is this design feature that leads to some confusion on how to copy or migrate a custom plug-in from one server to another.
iManager 2.5 in same Tree sharing same RBS Collection (Scenario 2)
Let's begin with the second scenario. Note that iManager 2.5 requires eDirectory 8.7.3, and if it's on a NetWare Server, it must be at least NetWare 6.5 SP2 - but SP3 is highly recommended. Although this article calls it "moving custom plug-ins", it is really more of a migration process. Here's the step-by-step process.
Step 1, s2: Install iManager 2.5 on the target server. This server must already be installed in the same eDirectory tree as the iManager 2.0.2 server you want to transfer the custom plug-ins from. The process for installing iManager 2.5 (and NetWare 6.5 SP3, if needed) is already well-documented, so I will not go into the details of that here.
Step 2, s2: The key to migrating your custom plug-in from one server to another is to log in as one of the user objects that is a Collection Owner of the RBS Collection you are going to migrate the custom plug-in from. Collection Owner objects have an attribute on their object listing the collection(s) they act as owner for. This link allows the first-time login on a new iManager 2.5 to find the original collection. The link also allows the collection to be upgraded, and it does the other steps necessary to get the custom plug-in to the new server.
To check who the collection owners of the RBS collection are, go to the Configure page, expand the Collection Configuration role, and select the Modify Collection Owners task. The screen shot below is from the iManager 2.0.2 installation, showing who is already in the collection owners list. Collection owners can add other users to be owners from this same page, if needed.
Figure 1: Modify Collections Owners
Note: The rest of the iManager 2.5 screen shot examples in this article are shown using Mobile iManager. However, the effects would be the same from a regular server-based iManager.
Step 3, s2: Complete the tasks listed below:
- From the Configure page, go to Role Based Services.
- Select the RBS Configuration task. It will bring up the RBS Collection name on the 2.x Collections tab. Unless an iManager 2.5 installation has already occurred somewhere in this same tree, at the top of the screen will be a message stating: Notice: The RBS schema definitions have not been installed or they are out of date. Extend schema now.
- Click the Extend Schema link to extend the schema for iManager 2.5 now. This will only take a moment.
- Click OK on the completion screen to return you to the main RBS Collections screen (the message about extending schema will be gone). If this server does not hold a copy of the root partition, you may need to wait for schema synchronization to complete before continuing.
Figure 2: RBS configuration
Step 4, s2: On this RBS Configuration screen, there are 4 columns of numbers listed. If there is a value greater than zero in the third column (Out-of-Date), then you need to upgrade those modules by following these steps:
- Click the number (a hyperlink) in that column. This will display a list of modules that need upgrading.
- Click the box at the top next to the TYPE column header to select all the modules.
- Click Update to upgrade all the plug-ins for 2.5 so they operate properly. If you still want to use 2.0.2 iManager on the original server, it will still function fine.
- Repeat the process for the "Not Installed" modules in the fourth column if you want them also.
These steps so far are just the basic preparation that is necessary for any shared RBS Collection situation. Now we are ready to actually migrate the custom plug-in:
Step 5, s2: From the Configure page, expand Role Based Services and select the Plug-in Studio task.
All your custom plug-ins should appear in the list of available plug-ins. They are not actually installed on the server yet; this list was just populated from the Collection object.
This sample custom task is also contained by a custom Role. Since we are using the same collection, we don't need to re-create the custom Role. It will be done automatically, since roles are maintained in the Collection itself, not in the file system under the Tomcat directory structure (like the actual NPMs that contain the code for each task).
Figure 3: iManager Plug-in Studio
Step 6, s2: For each plug-in that you want installed and available, complete these tasks:
- Click the check box next to the Plug-in ID name, and select the Edit function. This will display the plug-in studio editor for your plug-in.
- If you want, you can make changes to your plug-in. All you need to do is then select the Install function at the top of the screen, and the plug-in will be installed. If you had a custom role, it will be created also, and then it will appear in your available roles list from the "Roles and Tasks" page.
Figure 4: Plug-in Studio fields and properties
At this point you should be ready to go. If you want additional users to access the role(s), you may need to assign them the rights to it as you did for the iManager 2.0.2 server.
Figure 5: Newly installed custom role and task now available
iManager 2.5 in different Tree or different RBS Collection (Scenario 3)
In iManager 2.5, a new capability was added to the Plug-in Studio - exporting and importing plug-ins. Since this feature didn't exist for iManager 2.0.2, we had to go through all the steps listed above to transfer the plug-in to a different iManager 2.5 server sharing the same collection. It is not possible to directly transfer a custom plug-in from an iManager 2.0.2 server to any other iManager that is not sharing the same collection.
However, you can work around that limitation. First you must follow all the steps listed above to migrate the custom task to an iManager 2.5 server. I used Mobile iManager in the example above to show that you don't really need to install a new iManager 2.5 server in your original tree, if you only want to be able to export your custom plug-in to a new tree. Mobile iManager can be installed on a workstation; then you can login to the RBS Collection of an iManager 2.0.2 server without impacting the existing server environment at all.
After getting your custom plug-in migrated to the iManager 2.5 server, you then follow these steps:
Step 1, s3: Complete these tasks:
- Go back to the Plug-in Studio on the Configure page.
- Select your plug-in, then click Export under the Actions dropdown menu.
- Click Save. A file save dialog appears so you can specify where you want the exported NPM file to be saved. Plug-in Studio will save your custom task in an NPM file named like "custom_<date>_<time>.npm".
Figure 6: Plug-in Studio, Exporting
A dialog appears, asking if you want to open or save the file.
Step 2, s3: Copy the exported npm file to a location accessible by the new iManager 2.5 where you want to import the custom plug-in.
Step 3, s3: Go to the new server and launch iManager 2.5. If any of the custom Tasks you have are stored in custom Roles, then the Roles must be manually created first. To create the role, do the following:
- Go to the RBS Configuration page.
- Click the collection name. The first screen that comes up is the Roles tab.
- Click New and select the iManager role. This launches the Role Creation Wizard.
- Fill in the Role name in the first page. Be sure to use exactly the same name as the custom role from the original version. You can add a description if desired. Click Next.
- Click Next on the following two screens that deal with selecting the Tasks and Assigning Categories. We don't need to do anything with those yet. Importing the custom task below will do the task assignment for us.
- On the fourth screen, you need to fill in the name and scope of where you want this role to be available. This should be similar to how you defined it in the original tree.
- Click Add to decide if you want to keep the default rights assigned there.
- Click Next. In this case, I let eDirectory rights determine if a task can be performed, so I unchecked the Assign Rights box. This example shows that my admin user will have this task available throughout the entire tree.
- Click Next to continue to the summary screen.
- Click Finish, and your custom role is created.
Figure 7: Role Based Service Collection
Figure 8: Role Creation Wizard
Figure 9: Assigning members and scopes
Step 4, s3: Go to the Plug-In Studio and click Import under the actions heading.
Figure 10: Plug-in Studio, Importing
Step 5, s3: Complete these tasks:
- Fill in your collection.
- Browse to the file you exported in Step 2 above.
- Click Import. This will copy the plug-in to your system, but it is not yet installed. Your custom plug-in will now show up in the list of custom plug-ins.
- Check the box next to your custom plug-in and click Edit.
Figure 11: Importing Plug-ins
Figure 12: Plug-in fields and properties
Step 6, s3: You can make changes now if you want, but all you need to do is click Install. Make sure the role that will contain this task matches the custom role you created, if you needed one. If you want to make a different role, this is where you can set the new role this task will be associated with. Clicking Install at the top of the screen will install the custom plug-in into your collection, in the custom role if you created one. After the install completes, it is ready and available to be used.
Figure 13: Plug-in migration completed
Custom tasks show up now where they were before, unless you changed the Role you created during the installation process. In this example, a custom role was created to hold the custom task. If your custom task was assigned to some other pre-existing role, that is where it will show up.
It's just that easy. By following these steps, you now have transferred your custom iManager 2.0.2 task to a new server in a new tree.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com