BookmarkSubscribeRSS Feed
☑ This topic is solved. Need further help from the community? Please sign in and ask a new question.
thedcoii
Obsidian | Level 7

We changed the IP address of one our machines and now when I try to publish even the most simple decision I get the following on that server and not on any of the others. 

 

"modelName":"testdecision123","log":"ERROR===Could not obtain a token from \"http://<servername>\"."

 

Any ideas where I update the IP on the design time server or do I have to remove and re-add this one as a publish destination?  

1 ACCEPTED SOLUTION

Accepted Solutions
thedcoii
Obsidian | Level 7

This ended up being the 'identities' service. We had a bad memory setting in the identities service which made it so it was unable to start. The message in the specific identities service log was obvious. When fixing those and restarting the identities service the publishing was able to complete.

 

One of the ways we found this was in the development environment where the publishing was working if we set bad credentials we'd get the same error. So the assumption which turned out to be correct was that the authentication wasn't acting correctly. 

View solution in original post

8 REPLIES 8
gwootton
SAS Super FREQ
We should be resolving the IP address from DNS, does nslookup return the correct IP address on that server?
--
Greg Wootton | Principal Systems Technical Support Engineer
thedcoii
Obsidian | Level 7

yes I was hoping it was by url alone but it was registered before with a different ip address. 

 

I guess I could just use the api to remove it and re-register the destination. 

 

Is this how you would suggest re-adding it? 

 

 

gwootton
SAS Super FREQ
Did you supply the old IP address when registering the destination? If not, I would not expect SAS to capture and store this. I would say recreating the destination sounds like a valid next step in troubleshooting. I'd be interested to know if that resolves the issue.
--
Greg Wootton | Principal Systems Technical Support Engineer
thedcoii
Obsidian | Level 7

Yes I don't think the IP address is directly involved as even in the prior registration processes I believe we just use the DNS name rather than the IP. 

 

Still, I've always struggled registering new publishing destinations as it doesn't seem there is a great way to do it from the environment manager. Whenever I try and do it through the api (https://<servername>/modelPublish/destinations) I always run into issues with content types etc. 

 

Do you know any good resources or how to create and add publishing destinations for mas easily? 

gwootton
SAS Super FREQ
The documentation for creating publishing destinations can be found here:

Viya platform: Create a New Publishing Destination
https://go.documentation.sas.com/doc/en/sasadmincdc/v_042/calpubdest/p02scrqf37kexwn1gi60khpshifz.ht...

Viya 3.5: Create a New Publishing Destination
https://go.documentation.sas.com/doc/en/calcdc/3.5/calpubdest/p02scrqf37kexwn1gi60khpshifz.htm#n1dek...
--
Greg Wootton | Principal Systems Technical Support Engineer
thedcoii
Obsidian | Level 7

So this doesn't appear to be related to the change of IP address as we are getting it on three of our four servers now. For mas local it is publishing as expected but for the three remotes it is giving the can't obtain token error. 

 

We made some changes to rights of active directory accounts which I think maybe part of the culprit but I don't know how to test or validate this. 

thedcoii
Obsidian | Level 7

I'm seeing this too in the logs. 

 

Our 'grace' period is till OCT so I don't think it is related, however it is odd that we started seeing issues the day after our original expiration. 

thedcoii
Obsidian | Level 7

This ended up being the 'identities' service. We had a bad memory setting in the identities service which made it so it was unable to start. The message in the specific identities service log was obvious. When fixing those and restarting the identities service the publishing was able to complete.

 

One of the ways we found this was in the development environment where the publishing was working if we set bad credentials we'd get the same error. So the assumption which turned out to be correct was that the authentication wasn't acting correctly. 

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

Get Started with SAS Information Catalog in SAS Viya

SAS technical trainer Erin Winters shows you how to explore assets, create new data discovery agents, schedule data discovery agents, and much more.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 8 replies
  • 948 views
  • 0 likes
  • 2 in conversation