It’s all about the timing. If this had happened a week ago I’d be tossing a Maltov at the AD licensing office, where ever that might be. Not only that, but I lost my motherboard last month, so I have a complete restoration package already on hand with user setups and hotkeys and python.
2 Likes
Well I hope they realize that they do have a serious problem and have temp licenses on hand. This isn’t really an acceptable scenario for a software like this.
Meanwhile, I just got a survey from the ADSK Identity team as they’re thinking about adding PassKey to the options of signing in. In the extra notes at the end I did mention Linux compatibility. Gave them a bit of an earful in my answers.
Maybe they should think less about new options, until their current options work reliably.
2 Likes
I just noticed that we set the environment variable setenv DL_INTERNET_STATUS no
I don’t remember why we have this, but maybe it is why we have never had any of the insanity issues described in this thread.
I still have my old drive connected. Where might I find this? And I never had any of this insanity unti I suddenly did.
Not sure what this env is for, but this is how you set it. It mentions restarting s+w afterwards, so likely storage and not license related.
echo 'DL_INTERNET_STATUS=no' | sudo tee -a /opt/Autodesk/cfg/env.cfg
source: Solved: You don't have permission to access... - Autodesk Community
Not clear if it’s the same issue or just in the same area… I do remember seeing the errors mentioned in this article on my Linux Flame and so far had no login issues.
While searching for that, also came across these:
(exact error message you’re seeing, suggests to clean up /etc/resolve.conf)
also pointing to /etc/resolv.conf
Not clear how resolv.conf would suddenly be wrong if nothing else was installed.
Some additional debugging steps to restart the licensing service after retry count has been exceeded: https://www.autodesk.com/support/technical/article/caas/sfdcarticles/sfdcarticles/Error-Retry-limit-exceeded-connecting-to-the-Service-ERROR-Licensing-Error-in-Flame.html
(though I would imagine that a reboot would do the same, though some of the log-out/login steps at the end could clear out cached login states.)
If you’re more adventurous, here are a few more I found while Googling this issue… Some of them are for Flame, some for AutoCAD, but they use the same underlying license service.
Good candidate:
Instructions on how to reset the license service for Flame. Instructions are for CentOS, but that’s recent enough.
Another one for Flame, resetting the license information. Includes Linux instructions.
I think this is a variation of the same - scroll down to subscription licenses:
https://www.autodesk.com/support/technical/article/caas/sfdcarticles/sfdcarticles/Forcing-re-activation-of-product.html#subscription
This is more on the root certificates. Windows instructions, we’d have to find the Rocky equivalent to the certificate manager.
I would imagine their support would have gone through all of those already, but then you never know…
This basically gets rid of a benign error message that spams the shell.
1 Like
Wow, didn’t realize how much went on here last week. I thought I had updates turned on for this thread but apparently not. Sorry I wasn’t here for moral support.
Anyway… I finally had a zoom with a bunch of the licensing programers in Asia last night. After an hour and a half they were able to “hopefully” locate the issue and after two years, were finally able to get me able to sign back into my Autodesk license without an OS reinstall.
The issue had something to do with messed up with the SSL certificates - you were on the right trail, Jan… So we have a fix that worked (at least one time) for me on my rig and now and they’re going to investigate what might have caused the issue and hopefully prevent it in the future on their end.
With that being said, this was what they did on my system (Beau from AD support was involved with this case from the start, so if you need additional assistance I’d file a case and try to get in touch with him for more help). To restate, these are the steps I followed when I tried to log into my Autodesk user license on Rocky and received the error stating I could not make an internet connection to Autodesk (even though the machine was connected to the internet without any FireWall impedance):
-
Head to /etc/ssl/certs and do an ls -la
-
Look for any symlinks that are a series of 8 characters like this “663b494.0” and rename that symlink to a random name under 8 characters with a mv 663b494a.0 xyz.crt command
-
Bob’s your uncle! You should be able to connect to their license validation server now. YMMV, but worked a charm for me when trying to log in again after this tweak.
Let me know if you have any luck with this. I’m AD would love the feedback as well.
4 Likes
I would advise caution before editing anything in the SSL realm as the results may be permanant. As stated above, rename (mv) the file rather than deleting it. If in doubt, open a case and Flame support are able to assist. Please make sure you open a product support case and not a licensing case, it will save you time in the queue.
Indeed, proceed with caution. I know nothing about SSL and was told to tread lightly with changes. I’ll let you all know if I notice any ill effects of this change on my machine.
I still have my old drive and I took a look. Sure enough, there it is. It is not on my new drive. Interestingly enough, it is dated 5 days after my crash and burn. When I’m not in the middle of shipping big jobs, I will try booting up on the old drive and trying to connect. I’m not going to test it now.
Ah hah! Do you mind if I pass this along to Beau. I’m sure he’d appreciate the additional info.
1 Like
Absolutely.
Interesting… So here is what maybe going on, and it may not that dangerous.
On my system there are a few files in this folder, but none with this number pattern. Looking in what they represent, turns outs they’re hashes of actual certificates to speed up the certificate lookup. (source)
And the proper way of cleaning up this folder may actually be the following command
sudo update-ca-certificates -f
update-ca-trust
Adding -f to this command tells it to refresh the root certificate and remove all these hash value symlinks.
(see further down in thread for details)
This is the command that recreates these (source):
openssl rehash /etc/ssl/certs`
It seems some software prefers the hash value and some the human readable.
So it seems that somehow a hash value remained in the folder for a certificate that had expired or was removed. And that tripped up the license server from calling home, because it didn’t trust the connection. Getting this outdated file removed, cleared that up. That’s my guess.
Don’t belive every command you read on the internet. You may try run update-ca-certificates and scratch your head a bit. Likley update-ca-trust is the command you need in this instance.
Thanks for looking into this Jan.
SSL is WAY beyond my scope of knowledge, but I’m pretty sure the devs originally had us try that -f flag and it didn’t help the situation. It wasn’t until he manually renamed it that the issue resolved itself. I believe Beau also said that in Rocky the “update-ca-trust” command was the one to use instead of “update-ca-certificates”
I’ll be sure to share with the group info if I get it as to if/when they track down the culprit causing the issue.
1 Like
Fair enough. Variations between flavors of Linux.
In that case the system was ready to be scrapped, so trying something is still better than just re-installing.
I ran update-ca-certificates to no avail. But I appreciate the input.
See a few posts above. Try that command with -f.
I used the -f when I first tried it last week. At that point I would have tried hanging the entrails of a goat on the boughs of a bilabong tree at midnight inder a full moon.
2 Likes