Welcome Serena Central users!
The migration of the Serena Central community is happening today. Be sure to read THIS MESSAGE to get your new login set up to access your account.
kab12312 Respected Contributor.
Respected Contributor.
1246 views

eDirectory Migration - to new server

Found this paper and curious if anyone has tried it with eDirectory 9.1 This will be one of our LDAP servers. I can fail over to a different LDAP server during the migration.

https://support.microfocus.com/kb/doc.php?id=7012029#

I'll be migrating a SLES 12 server (non OES) to new hardware.

I'm working on a plan now for a future hardware migration. I can't really find any document so I'm piecing together a plan. Loved OES transfer ID. Wish there was a non OES option to migrate a SLES server!

Thank you!
Labels (1)
0 Likes
12 Replies
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: eDirectory Migration - to new server

On 12/10/2018 02:44 PM, ka12312 wrote:
>
> Found this paper and curious if anyone has tried it with eDirectory 9.1
> This will be one of our LDAP servers. I can fail over to a different
> LDAP server during the migration.


I moved two boxes from 8.8 SP8 to 9.1 last week using those same sort of
steps. I wrote that TID years ago, and the ndsrc.pl script that is
references, though it has been updated a bit since then and the TID could
use some updates today. For example, the only NICI data you should really
move over is the /var/opt/novell/nici/0 directory, NOTHING else, or else
the new much-updated version of NICI complains and you get -14xx errors
(as I saw on Friday).

I basically do this kind of "upgrade" anytime I can, especially when the
OS is involved, because it's so easy (if you are comfortable with the
command line), easy to rollback (just turn on the old box), and lets you
do so much testing on the new box ahead of time, or even with the final
DIB, before you commit to it (using iptables judiciously to prevent
communication with the rest of the environment).

In my case, this time, the IP addresses of servers actually changed (had
to; new VM environment used different ranges) but that was fine too; just
update the nsd.conf file before starting up.

> https://support.microfocus.com/kb/doc.php?id=7012029#
>
> I'll be migrating a SLES 12 server (non OES) to new hardware.


I went from SLES 12 SP1 to new SLES 12 SP3 boxes.

> I'm working on a plan now for a future hardware migration. I can't
> really find any document so I'm piecing together a plan. Loved OES
> transfer ID. Wish there was a non OES option to migrate a SLES server!


There is, in the form of that TID. It's great. Try it out once in a test
environment to be sure you are okay with it. If the command line is not
your friend, perhaps try something else; you need not be a guru, but the
procedure implies a knowledge of eDirectory and Linux, and both are
CLI-enabled.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
kab12312 Respected Contributor.
Respected Contributor.

Re: eDirectory Migration - to new server

I thought perhaps you wrote that TID.

I will be migrating: Source SLES 12 sp3 eDir 9.1 to SLES 12 sp3 eDir 9.1. New hardware and I will want the target server to take on the identity of the old (source) server.

Would it work to install the Target server with a RW replica, let things sync up, and then change all the config files to match the source server (once it is down).IP, nds etc.

Am I over thinking this. Seems I have done it that way in the past. Thoughts. Thank you!!
0 Likes
Knowledge Partner
Knowledge Partner

Re: eDirectory Migration - to new server

Don't even think about this. While it's in fact possible for a tree to survive this situation (with a bunch of other steps) i'd strongly recommend to just follow Aarons advice. Especially with your offset (same identity, same OS, same DS build) it'll save you time and headache.
0 Likes
kab12312 Respected Contributor.
Respected Contributor.

Re: eDirectory Migration - to new server

OK. Good advice. I am not finding a nsd.conf file (per Aaron) anywhere?
0 Likes
kab12312 Respected Contributor.
Respected Contributor.

Re: eDirectory Migration - to new server

Did he mean nds.conf?
0 Likes
Knowledge Partner
Knowledge Partner

Re: eDirectory Migration - to new server

Yes. Absolutely.
kab12312 Respected Contributor.
Respected Contributor.

Re: eDirectory Migration - to new server

Got it. Aaron, at what point do you take the Target server out of the temp Tree and put in the production tree. I think I read your TID correctly. Thank you!
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: eDirectory Migration - to new server

On 12/11/2018 08:26 AM, ka12312 wrote:
>
> Got it. Aaron, at what point do you take the Target server out of the
> temp Tree and put in the production tree. I think I read your TID
> correctly. Thank you!


Sorry about that 'nsd.conf' typo; super lame of me. If ever in doubt it
defaults to /etc/opt/novell/eDirectory/conf/nds.conf but it can be
anywhere, and you can always find it by running ndsmanage which will shwo
you the instance information, or check files under
/etc/opt/novell/eDirectory/conf/.edir/ in a file usually named instances.0
(for the 'root' user who has UID of zero (0)).

Regarding the "temp tree" option (and it is an option, but a good one), I
do not really take it out at all, but since the new server has the
hostname of the source server (the whole time), I just stop eDirectory
('ndsmanage stopall') and then move over the NICI and eDirectory instance
files. If you are able to isolate the new box from the old tree (meaning
no network connectivity until you are finally ready to move the
DIB/identity over from the source server) then you can even put the target
server into a tree with the same name, even having the same IP address
perhaps, just meaning it's a simpler migrate because of fewer
modifications to the nds.conf file.

If that's not an option, or maybe even if it is, you just need to be sure
that the values in the nds.conf file matches the target server when you
finally move things over; specifically be sure the treename reference is
correct (will be wrong if your temporary tree had a different name),
various IP addresses are updated, and be sure any references to the
server's hostname are updated. This is why I want to keep the new server
isolated while setting up a temporary tree, since I'll use the real tree
name and the real hostname (always), and then just maybe need to fix IP
addresses. This way the eDirectory systemd service is ready to go, and
all I need to do is stop eDirectory, copy in the data directory (which
holds the 'dib' directory), and the NICI data (/var/opt/novell/nici/<uid>
which is usually /var/opt/novell/nici/0), then start up eDirectory.

I also like to keep the new server completely isolated via iptables
trickery until I have it fully up and at least responding to LDAP queries;
I do this with a command like the following, assuming servers are using
TCP 524 for communication as is the default:


sudo /usr/sbin/iptables -I OUTPUT -m tcp -p tcp --dport 524 -j REJECT
--reject-with icmp-port-unreachable
sudo /usr/sbin/iptables -I INPUT -m tcp -p tcp --dport 524 -j REJECT
--reject-with icmp-port-unreachable


These commands basically mean that this box (the target box) will not be
able to talk to anybody, inbound or outbound, on TCP 524. eDir can then
load, NICI issues can be resolved (if applicable), LDAP queries can be
tested, even IDM might work if applicable, the CA can be tested (if the
Certificate Authority (CA) is on this box), and on and on.

If things go wrong at some point, since this server has not talked to any
others in the tree, wiping its DIB out and restoring it again to give it
another shot is legal, where otherwise if you bring up the box an it
starts replicating you really shouldn't restore an old DIB because it's a
bad idea.

When you're done, either reboot the box to lose the old rules, or delete
the rules by changing -I (insert) to -D (delete) in the iptables commands:


sudo /usr/sbin/iptables -D OUTPUT -m tcp -p tcp --dport 524 -j REJECT
--reject-with icmp-port-unreachable
sudo /usr/sbin/iptables -D INPUT -m tcp -p tcp --dport 524 -j REJECT
--reject-with icmp-port-unreachable


Going back to your question about removing from the (single server)
temporary tree, just stop the service (do not remove it, leaving the
nds.conf and various directories in place). Replace the NICI and
eDirectory directories with the source server's, then update the nds.conf
file, and start things up again ('ndsmanage startall') and it's done.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
kab12312 Respected Contributor.
Respected Contributor.

Re: eDirectory Migration - to new server

Thank you!! I'll be testing this soon. I'll let you know how I did. Thank you again so much!!

ab;2492407 wrote:
On 12/11/2018 08:26 AM, ka12312 wrote:
>
> Got it. Aaron, at what point do you take the Target server out of the
> temp Tree and put in the production tree. I think I read your TID
> correctly. Thank you!


Sorry about that 'nsd.conf' typo; super lame of me. If ever in doubt it
defaults to /etc/opt/novell/eDirectory/conf/nds.conf but it can be
anywhere, and you can always find it by running ndsmanage which will shwo
you the instance information, or check files under
/etc/opt/novell/eDirectory/conf/.edir/ in a file usually named instances.0
(for the 'root' user who has UID of zero (0)).

Regarding the "temp tree" option (and it is an option, but a good one), I
do not really take it out at all, but since the new server has the
hostname of the source server (the whole time), I just stop eDirectory
('ndsmanage stopall') and then move over the NICI and eDirectory instance
files. If you are able to isolate the new box from the old tree (meaning
no network connectivity until you are finally ready to move the
DIB/identity over from the source server) then you can even put the target
server into a tree with the same name, even having the same IP address
perhaps, just meaning it's a simpler migrate because of fewer
modifications to the nds.conf file.

If that's not an option, or maybe even if it is, you just need to be sure
that the values in the nds.conf file matches the target server when you
finally move things over; specifically be sure the treename reference is
correct (will be wrong if your temporary tree had a different name),
various IP addresses are updated, and be sure any references to the
server's hostname are updated. This is why I want to keep the new server
isolated while setting up a temporary tree, since I'll use the real tree
name and the real hostname (always), and then just maybe need to fix IP
addresses. This way the eDirectory systemd service is ready to go, and
all I need to do is stop eDirectory, copy in the data directory (which
holds the 'dib' directory), and the NICI data (/var/opt/novell/nici/<uid>
which is usually /var/opt/novell/nici/0), then start up eDirectory.

I also like to keep the new server completely isolated via iptables
trickery until I have it fully up and at least responding to LDAP queries;
I do this with a command like the following, assuming servers are using
TCP 524 for communication as is the default:


sudo /usr/sbin/iptables -I OUTPUT -m tcp -p tcp --dport 524 -j REJECT
--reject-with icmp-port-unreachable
sudo /usr/sbin/iptables -I INPUT -m tcp -p tcp --dport 524 -j REJECT
--reject-with icmp-port-unreachable


These commands basically mean that this box (the target box) will not be
able to talk to anybody, inbound or outbound, on TCP 524. eDir can then
load, NICI issues can be resolved (if applicable), LDAP queries can be
tested, even IDM might work if applicable, the CA can be tested (if the
Certificate Authority (CA) is on this box), and on and on.

If things go wrong at some point, since this server has not talked to any
others in the tree, wiping its DIB out and restoring it again to give it
another shot is legal, where otherwise if you bring up the box an it
starts replicating you really shouldn't restore an old DIB because it's a
bad idea.

When you're done, either reboot the box to lose the old rules, or delete
the rules by changing -I (insert) to -D (delete) in the iptables commands:


sudo /usr/sbin/iptables -D OUTPUT -m tcp -p tcp --dport 524 -j REJECT
--reject-with icmp-port-unreachable
sudo /usr/sbin/iptables -D INPUT -m tcp -p tcp --dport 524 -j REJECT
--reject-with icmp-port-unreachable


Going back to your question about removing from the (single server)
temporary tree, just stop the service (do not remove it, leaving the
nds.conf and various directories in place). Replace the NICI and
eDirectory directories with the source server's, then update the nds.conf
file, and start things up again ('ndsmanage startall') and it's done.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
Highlighted
kab12312 Respected Contributor.
Respected Contributor.

Re: eDirectory Migration - to new server

Still waiting on a test environment 😞

Additional question. Can you do a hardware migration from OES 2015.1 Linux to just plain SLES 12. These servers are only used for LDAP. There are no volumes other than SYS. They don't want OES anymore. No need. Thanks!
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: eDirectory Migration - to new server

On 01/04/2019 02:06 PM, ka12312 wrote:
>
> Still waiting on a test environment 😞


Ah, the ancient battle. Sorry about that. VMs on laptops or desktops
will do in a pinch.

> Additional question. Can you do a hardware migration from OES 2015.1
> Linux to just plain SLES 12. These servers are only used for LDAP.
> There are no volumes other than SYS. They don't want OES anymore. No
> need. Thanks!


If you do not need the OES-ish services, then I do not see why not, but
there may be a few things to clean up; going the other way (non-OES to
OES) is harder, probably not a good idea, but going from OES to SLES is
probably fine enough.

On the other hand, if these are JUST eDirecgtory boxes (no IDM, no
volumes, nothing but eDirectory) it might be just as easy to add a new
server into the tree, add replicas, and turn th eold one off, and that
would not be problematic if you had issues along the way. I'm not saying
you SHOULD do it this way, but others who are not familiar with eDir and
Linux come along, the supported/documented way may be nice if all things
are equal.

If IDM's in the mix, I'd definitely try the migration you're planning,
though; moving driver objects from server to server is something I try to
avoid.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
Knowledge Partner
Knowledge Partner

Re: eDirectory Migration - to new server

ab;2493197 wrote:
On 01/04/2019 02:06 PM, ka12312 wrote:
>
> Still waiting on a test environment 😞


Ah, the ancient battle. Sorry about that. VMs on laptops or desktops
will do in a pinch.

> Additional question. Can you do a hardware migration from OES 2015.1
> Linux to just plain SLES 12. These servers are only used for LDAP.
> There are no volumes other than SYS. They don't want OES anymore. No
> need. Thanks!


If you do not need the OES-ish services, then I do not see why not, but
there may be a few things to clean up; going the other way (non-OES to
OES) is harder, probably not a good idea, but going from OES to SLES is
probably fine enough.

On the other hand, if these are JUST eDirecgtory boxes (no IDM, no
volumes, nothing but eDirectory) it might be just as easy to add a new
server into the tree, add replicas, and turn th eold one off, and that
would not be problematic if you had issues along the way. I'm not saying
you SHOULD do it this way, but others who are not familiar with eDir and
Linux come along, the supported/documented way may be nice if all things
are equal.

If IDM's in the mix, I'd definitely try the migration you're planning,
though; moving driver objects from server to server is something I try to
avoid.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.


In a migration scenario, don't forget to check the host for the certificate server (move or recreate as needed) and check the SDI infrastructure / tree keys to make sure everything there is healthy afterward. Fix as needed.
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.