Media clientid db, internal client table, how to treat DNS changes

You can not do anything except displaying the Client ID (mminfo) and deleting a client from the database. But there is no function to display a table for all clients and their associated Client ID.

1) sometimes 2 DNS names point to one IP address; I think networker  actually allows you to create 2 such clients with different names. What  happens to indices in such case?

NW will only create 2 index directories when you specify the short name first and create another instance with the FQDN. But as the short name is an alias for the FQDN, there should not be any need to physically merge the CFIs.

2) The customer sometimes deletes  a client (even from DNS). What would you do to retain the backups in  NetWorker for a while? mminfo seems to complain about not being able to  resolve the name.

Just add an appropriate entry in the hosts file.

ondrejpalkovsky wrote: 1) sometimes 2 DNS names point to one IP address; I think networker actually allows you to create 2 such clients with different names. What happens to indices in such case? 2) The customer sometimes deletes a client (even from DNS). What would you do to retain the backups in NetWorker for a while? mminfo seems to complain about not being able to resolve the name. What are the recommended procedures when something like this happens?

1) As long one of them is alias that is not a problem.  Client should be defined over the name for the card/IP used to backup using A record and not CNAME one.  CNAME should be placed in alias list of NetWorker client resource used to create FQDN based on A record.

2) Add false/bogus entry to server's /etc/hosts

Well.. ok, what happend to us is this: the customer is using something like 'olddomain.com' and 'newdomain.com' internally in the company. He renamed a computer from oldname.olddomain.com to newname.olddomain.com. Unfortunately newname.newdomain.com has an A record pointing somewhere else. When we started configuring the system, we missed this and created oldname.olddomain.com and newname.newdomain.com. Then, after realizing this, I removed newname.newdomain.com, created newname.olddomain.com, and later, after finding that we actually have 'newname' and 'oldname' there, the oldname.olddomain.com being actually a CNAME for newname.olddomain.com, I removed the 'oldname.olddomain.com'.

To cut the story short: now everything works, but the CFI is (daily?) totally purged for this client. This is very likely some problem with internal clientid table or some IP adress/clientid mapping - but I have no idea how to solve it. Any suggestions?

Twisted

When this sort of things happen (index data removed) it usually indicates that after crosscheck between indx db and mdb it was found that index has been saved under wrong client.  Indeed, that could be client id thingy (mminfo -avot -r client,clientid | sort -u -k1 might help find it).  You may also check with nsrls the clients (eg. for client in `mminfo -avot -r client | sort -u`;do nsrls $client;done) and their index path and at the end check if any of those has nested home.  Most likely it does.  Since focus here is on XXX client you may limit above to qieries against that client only.  To see what client thinks of itself, you can do nsradmin query from server and check name field (echo p | nsradmin -p 390113 -i - -s )

In case somebody would find it useful, I have created a small python thing that dumps the 'client' table from media database. Unfortunately, it can show only the 5 of the 6 parts of the clientid; the 6th part is likely some kind of checksum....if I could find the algorithm for the checksum, it would be very helpful for solving the 'clientid mess' problem (i.e. we have both short and long names in the clients table and it causes big problems). Does anyone have any idea, what the algorithm might be?

Man, it is so obvious   6th pair or client-id sausage is hexed IP address of backup server (or more precisly, physical node on which backup server is active when client is being created first time).  If you check, most clients would have that 6th part the same.  In my case it is0af6f05a which translates 10.246.240.90 (which is nothing more but IP of physical system which is standby server in cluster).

I wasn't clear - it wasn't 6-th part in the ordinal sense; it was 6th as in "I know what 5 parts mean". In the clientid (and ssid) the unknown part is the 1st part. It is not part of the client file table, it is not part of ssid identifier in savesets (you can see the format of media described on man page - ssid is 20 bytes). Its probably some checksum...

I would like to know how to find out a client-id for a client that no longer has save sets in the media DB. I am having an issue where the client IDs got crossed when someone changed the name of a client from FQDN to short.

danny.villanueva@emc.com

Remove all references to the client from networker client configuration (both short and fqdn). Recreate a client with the name you want to find out the client id (i.e. if you want to know the clientid of the FQDN, create client with FQDN). Read the client id

ondrejpalkovsky wrote: Remove all references to the client from networker client configuration (both short and fqdn). Recreate a client with the name you want to find out the client id (i.e. if you want to know the clientid of the FQDN, create client with FQDN). Read the client id

That's not correct. If all references in mdb are gone, new client-id will be created (unless cached value will be used). Given that some time probably has passed, it likely that this information is gone.

However, if all mdb entries are gone, I wonder why it is necessary now to know client-id and what kind of the issue are you facing exactly? Because fact that you don't have any entried in mdb is a bit confusing.  Unless you are referring to FQDN entries and now you have just short.  If so, just leave it as it is.  If you wish to change it, just follow the procedure to rename the client.  Otherwise, explain what is the issue that you see. 

Bonus tip: since you are EMC guy, I can just assume you are either supporting customer in some sort of way, but then you should ask questions like this to internal part of the forums - which is designed for EMC folks.  Otherwise it looks a bit silly that vendor guy is asking this sort of question.

It is correct. There is an internal database of hostname->clientid somewhere in /nsr/mm/client.* - you can type the client names by running 'strings '. The clientid/clientname combination stays in this database forever, regardless of the configuration database. The only way to modify this database using 'legal' procedure is creating new clients and renaming clients.

The reason you have to delete all references from configuration database to both FQDN and short name is that networker generally doesn't allow you to create a name that conflicts with an alias; fqdn will have a shortname as an alias and they will both map to same IP adress which might conflict inside networker too.

Just tested it - I'm right. Created new client, removed client, run "nsrck -m", restart networker, created same client again - got same clientid.

Rereading it again, you may be right - does really networker delete references to old clients from /nsr/mm/client database if all references to saveset are gone? I'm going to test it...

Hi,

Client list (ever configured) is in clients.0, but not their clientid from what I see.  I can also confir that it didn't take original clientid in my case - I happen to have some snapshots of early clients I had and I just added one and compared clientid and it is not the same - this is (now) HPUX 7.6SP5 (originally back then it was 7.4SP?).  I would be surprised to hear that this is working different on different platforms.

OK, I will have to check this... and hex search older client-id which is not what I get now.