Introduction
My last post was Migrating a NetEye Server to New Hardware (Part 1), so take a look at that one if you haven’t already and then continue reading the rest of the Migration process here.
Fix Unix Users and Groups (Only on Clusters)
The NetEye installation process unfortunately doesn’t fix user/group ID’s for the necessary Unix users and/or groups the product needs to run. This means that when you operate on a cluster and a shared filesystem like DRBD, the User-ID and Group-ID of the files there are fixed, and are synchronized AS-IS on the other node(s).
That means all cluster nodes need to have the same User- and Group-ID’s, and in fact there’s a NetEye health check that verifies the status of the ID’s for this very reason. Obviously any newly added hardware which has a “standard” installation procedure most likely has different ID’s, and so you’ll have to first adapt the Group-ID’s and then the User-ID’s to match those on the old server nodes.
This isn’t as straightforward as you might think, since changing the Group-ID and/or User-ID means that you have to change the ID on all files that belong to this group and/or user before you can change them in the /etc/group or /etc/passwd file. I’ll try to explain how you can do this.
Changing the /etc/group File
To discover what’s different between the old and new nodes, you first have to get the /etc/group file sorted on the new node.
After locating the files on the new node, you can diff the files to see the differences (diff g1 g2), or just have them open in a text editor and go through them one by one aligning the ID’s, changing the ID on the new node to the ID from the old node in the following manner:
OldNode: cat /etc/group |
sort >/root/g1
scp /root/g1 newnode:/root/NewNode: cat /etc/group |
sort >/root/g2Example using Tornado: Let’s take “tornado:x:407:” on the OLD node(s) and “tornado:x:408:” on the NEW node. You’ll first have to change the Tornado files to the new GID with this command:
find / -group 408 -exec chgrp 407 \{\} \;
After that just change the row in the /etc/group file of the new node to the 407 ID “tornado:x:407:“. Do this with all groups. Add any missing groups which are on the old node to the new node, paying careful attention that the GID of that group is not already used by some other group; otherwise you’ll have to change that GID(s) first.
IMPORTANT: If on the old node there are additional users in the group line, add them to to the new node. For example, given “icinga:x:998:sahi” on the old node, and “icinga:x:512:” on the new node, first align the GID of the new node to 998, and then add the sahi user to the icinga group just as you see it on the old node.
Changing the /etc/passwd File
To discover what’s different between the old and new nodes, you first have to get the /etc/passwd file sorted on the new node.
After locating the files on the new node, you can diff the files to see the differences (diff p1 p2) or just have them open in a text editor and go through them one by one aligning the ID’s, changing the ID on the new node to the ID of the old node like this:
OldNode: cat /etc/passwdp |
sort >/root/p1
scp /root/g1 newnode:/root/NewNode: cat /etc/passwdp |
sort >/root/p2
Example: Let’s again take Tornado where we have “tornado:x:408:407:tornado:/home/tornado:/sbin/nologin“on the OLD node(s) and “tornado:x:411:408:tornado:/home/tornado:/sbin/nologin” on the NEW node. First you’ll have to change the Tornado files to the new UID (the GID is already done at this point) with this command:
find / -user 411 -exec chown 408 \{\} \;
After that, just change the row in the /etc/passwd file of the new node to the identical line of the old node, as the GID of this row on the new node is already adapted and is thus wrong. Do this with all users.
Finally, add any missing users who are on the old node to the new node, paying close attention that the UID of that user is not already in use by some other use; otherwise you’ll have to change that UID(s) first.
So this ends our 2nd Part for Migrating a Neteye Server to a new Hardware. The 3rd and final part of the Migration process is coming soon.
End of Part 2
These Solutions are Engineered by Humans
Did you find this article interesting? Does it match your skill set? Our customers often present us with problems that need customized solutions. In fact, we’re currently hiring for roles just like this and others here at Würth IT Italy.
Juergen Vigna
NetEye Solution Architect at Würth IT Italy
I have over 20 years of experience in the IT branch. After first experiences in the field of software development for public transport companies, I finally decided to join the young and growing team of Würth Phoenix (now Würth IT Italy). Initially, I was responsible for the internal Linux/Unix infrastructure and the management of CVS software. Afterwards, my main challenge was to establish the meanwhile well-known IT System Management Solution WÜRTHPHOENIX NetEye. As a Product Manager I started building NetEye from scratch, analyzing existing open source models, extending and finally joining them into one single powerful solution. After that, my job turned into a passion: Constant developments, customer installations and support became a matter of personal. Today I use my knowledge as a NetEye Senior Consultant as well as NetEye Solution Architect at Würth Phoenix.
Author
Latest posts by Juergen Vigna
22. 05. 2025
NetEye, Unified Monitoring
Automatic Integration of NagVis Map into Icinga Web 2/NetEye Monitoring