Tool for editing domain databases

Recently I checked the database entries for my MTAs, Internet Agents and POAs, because i saw a path in a log, which does not exist since years.

In this case it was the UNC-path (attribute-ID 59003), which is totally wrong for this agent, because it points to a server, which was removed several years ago. I know, that one could set this attribute via C1 as long as the groupwise system was integrated into eDir, but now, I don't see any tool to change this value. Although that value seems to be not used any more I see this value still popuated in a newly installed internet agent, but it does not show an UNC-path - it simply shows the linux filesystem-path to the internet agent.

How can I get rid of those irritating entries, because if someone has to take over the administration of this system, this will at least lead to unneccessary thoughts. And I hate carrying along wrong entries - even, if they do not harm and apparently are not used.

Parents
  • 0  

    What is the record showing when using the REST API?

    https://gwserver:9710/gwadmin-service/domains/DOM_NAME/mta

    As i dont have this i like to see the full record as this probably can be used to make a REST API call using Curl to empty or remove this field

  • 0 in reply to   

    The REST API for this Internet agent (the mtas are ok) shows for the url:

    https://GWIAserver.x.x:9710/gwadmin-service/domains/DOM-NAME/gwias/GWIA-NAME

    the line

    "path": "\\\\Pc_burghardt_d\\C\\grpwise\\INETDOM\\WPGATE\\GWINAG", in JSON style
    in XML translation it would be <path>\\Pc_burghardt_d\C\grpwise\INETDOM\WPGATE\GWINAG</path>
    which is completely nonsense as it is a Windows path, for a machine, which was retired more than 10 years ago and the rest of the path is incorrect, too - with the exception of WPGATE.

    the entry for the

    "smtpQueuesDirectory": "/media/nss/VOL03/DOM-directory/wpgate/GWIA-NAME", in JSON sytle,
    which would be in XML <smtpQueuesDirectory>/media/nss/VOL03/DOM-directory/wpgate/GWIA-NAME</smtpQueuesDirectory>
    is correct and seems to be the correct value for the "path" entry, too. At least a newly installed GWIA shows a corresponding value
    The issue is only cosmetic, as everything is working since more than 10 years without problems.
  • Suggested Answer

    0   in reply to 

    I did some checking and the field is really old and as you seen no longer used. We used to allow configuring the path where the GWIA would place it’s files but we long since changed it and hard wired it to look at the domain and make it’s path relative to to wpgate and then the field DS_SUB_DIR ( field 50137 ) that has value "gwia" which is combined the full path.

    I tried to empty or remove this but the REST API wont allow this, the below was tried and is correct as any other field other then path with the same line can be changed/updated.

    curl -k --user admin:novell -H "content-type:application/json" -X PUT --data "{\"path\":\"\"}"  https://gwmain.robvk.com:9710/gwadmin-service/domains/MainDom/gwias/GWIA

    So it seems nothing we can do to remove this so just let it be

Reply
  • Suggested Answer

    0   in reply to 

    I did some checking and the field is really old and as you seen no longer used. We used to allow configuring the path where the GWIA would place it’s files but we long since changed it and hard wired it to look at the domain and make it’s path relative to to wpgate and then the field DS_SUB_DIR ( field 50137 ) that has value "gwia" which is combined the full path.

    I tried to empty or remove this but the REST API wont allow this, the below was tried and is correct as any other field other then path with the same line can be changed/updated.

    curl -k --user admin:novell -H "content-type:application/json" -X PUT --data "{\"path\":\"\"}"  https://gwmain.robvk.com:9710/gwadmin-service/domains/MainDom/gwias/GWIA

    So it seems nothing we can do to remove this so just let it be

Children
  • 0   in reply to   

    Hello Rob,

    yesterday I wanted to write that it is an orphand entry in GroupWise. In my Life GroupWise system which runs on LINUX, the UNC path for the primary domain is a Windows path ( \\hermes\gwise\pri-dom) which comes from a GroupWise 6.x system which was still running on Novell Netware.an ldapsearch against GroupWise LDAP did not produce any results either.  I have to say that I hope my query was executed correctly to find the attribute identifier that it concerns

    In my case, I solved the problem by swapping the primary domain with the secondary domain. Then I deleted the gwia of the now secondary domain. From this point on, there were no more objects in the secondary domain so that it could be deleted. Now I recreated the CA with gwadminutil force and redistributed it to the POAs. Created a new secondary domain, then swapped the primary and secondary domains again, then created a new gwia. Everything fine after that.  Maybe this is a possible solution to get the path out of the GIWA. As always - backup everything beforehand

    “You can't teach a person anything, you can only help them to discover it within themselves.” Galileo Galilei

  • 0 in reply to   

    Yes, I tested it now a second time, but it seems to be unchangeable - although the result of the put request is OK. Probably the value is read only in the database itself.