Habitat Build 1.0.1.5 Official Release Today

Support forums for the Habitat Automate plugin
Post Reply
User avatar
Cubert
Posts: 1898
Joined: Tue Dec 29, 2015 7:57 pm
Contact:

Habitat Build 1.0.1.5 Official Release Today

Post by Cubert »

After weeks of going over the new updates and making sure we have a solid release, we are pushing out Habitat 1.0.1.5 today.


Some of the new things to expect.
  • Tightened up the look and feel
  • New Application Manager
  • Numerous updates and minor fixes
You can log in to our web portal at www.plugins4automate.com to download the new updates or the Auto Updater should kick in over the next 48 hours.

dbitters
Posts: 19
Joined: Tue May 18, 2021 8:11 pm

Re: Habitat Build 1.0.1.5 Official Release Today

Post by dbitters »

The new version looks great, and I like the new name. I have a small suggestion initially.

In the applications manager UI at the customer level, can you either change the "Set as caching agent" to an enable/disable, or can you add a disable button below the set? I only say this because the interface wasn't behaving as expected with the right-click menu, and when I was setting the caching agent on a server, it actually set it on a workstation, a few below it causing two systems to show the icon of caching agent. Maybe there is a disable button to remove it from the incorrect system, but having it around the same place would be helpful to fix any missteps such as that. Much appreciated. The following day, I checked, and the incorrect system no longer showed as having the duplicate caching agent icon. Maybe your script detects the most recent selection and removes the prior selection after the next maintenance run.

I have a suggestion for an unrelated topic on the Habitat Powershell client console. The Dot.NET Versions tab, doesn't sort the Systems list as the other two tabs do. I don't suppose that can be auto sorted so it's not like trying to find a needle in a haystack on larger customers :-). Much appreciated.

dbitters
Posts: 19
Joined: Tue May 18, 2021 8:11 pm

Re: Habitat Build 1.0.1.5 Official Release Today

Post by dbitters »

We are still getting this log statement on each of our systems when the Application Manager Service runs:
"The agents location does not have a configured "Location Drive" or credentials to access drive, exiting script without agent changes."
Do you have any suggestions for this? I set the agent caching agent last week, and I still get this.

I should also note that also even after a week, the Installed Version column has been blank on all of our systems. The repo version collum is populating though. I know it's a work in progress, but in case it helps, I wanted to provide that info as well.
Thanks.

User avatar
Cubert
Posts: 1898
Joined: Tue Dec 29, 2015 7:57 pm
Contact:

Re: Habitat Build 1.0.1.5 Official Release Today

Post by Cubert »

dbitters wrote: Tue Oct 12, 2021 3:48 am The new version looks great, and I like the new name. I have a small suggestion initially.

In the applications manager UI at the customer level, can you either change the "Set as caching agent" to an enable/disable, or can you add a disable button below the set? I only say this because the interface wasn't behaving as expected with the right-click menu, and when I was setting the caching agent on a server, it actually set it on a workstation, a few below it causing two systems to show the icon of caching agent. Maybe there is a disable button to remove it from the incorrect system, but having it around the same place would be helpful to fix any missteps such as that. Much appreciated. The following day, I checked, and the incorrect system no longer showed as having the duplicate caching agent icon. Maybe your script detects the most recent selection and removes the prior selection after the next maintenance run.

I have a suggestion for an unrelated topic on the Habitat Powershell client console. The Dot.NET Versions tab, doesn't sort the Systems list as the other two tabs do. I don't suppose that can be auto sorted so it's not like trying to find a needle in a haystack on larger customers :-). Much appreciated.
How this should work is each location must have 1 and only 1 caching agent. If you select an agent and then select to set as caching agent it will take ownership on that role relieving the previous agent of that roll.

If this is not happening then let us know as it is working this way in our dev system currently.

User avatar
Cubert
Posts: 1898
Joined: Tue Dec 29, 2015 7:57 pm
Contact:

Re: Habitat Build 1.0.1.5 Official Release Today

Post by Cubert »

We are still getting this log statement on each of our systems when the Application Manager Service runs:
"The agents location does not have a configured "Location Drive" or credentials to access drive, exiting script without agent changes."
Do you have any suggestions for this? I set the agent caching agent last week, and I still get this.

I should also note that also even after a week, the Installed Version column has been blank on all of our systems. The repo version collum is populating though. I know it's a work in progress, but in case it helps, I wanted to provide that info as well.
Thanks.
This would make since if your not able to reach local cache. The Caching agent is getting repo data but either can not access the cache location or the agents trying to get cache can not access cache.

I suspect what you may have is a permissions issue. The caching agent must be able to write and read from location cache where all other agents just need to be able to read. So if you look on your cache location. Is there a Habitat/packages/ located on your Cache location?

If not then Caching agent can not access that share and write to it.

If the folder is there then caching agent can write to the share. You can look in the directory Habitat/packages/ for approved packages.



Also make sure that your caching location is correctly reflected here.

LocationCacheSettings.PNG
LocationCacheSettings.PNG (27.99 KiB) Viewed 147 times


~about one hour later~

A funny thing happened to me on the way to scripting a test for you to use.

As I was writing this post I side-stepped over to creating a test script you could deploy to see if a client is "Ready" for caching at a give location. Well as I wrote this script I kept getting a error about the cache password being null or blank. Well at first it was my fault as the client I was testing really didn't have a password set, my brain fart...OK set the password and still the same result. Well here is that little "gotcha", when you assume something, it typically makes an ass of you.

Here is no different, I can see that the password is "Hidden" in the variables available but, I assumed that when in the script language it was reveled. The developers just didn't want it visible in the debugger.

Capture.PNG
Capture.PNG (11.71 KiB) Viewed 147 times

However, this isn't so as I come to find out. I tried several methods to have it revel the actual passcode and every attempt returned null. So what's going on is that it is using the username but not passing the password as you would expect. If your share is fully accessible by everyone then this passes and all works as expected but if you expect the pass it fails to provide it as expected.

The funny thing is I can just query the locations table for it directly as my own variable so not sure why that is ... Automate is a fickle beast.

Anyhow I will be correcting this today and getting out another build to replace the current one.

I apologize to everyone that I didn't catch this oversight. our development agents and networks are not tightly secured so this got past us when configuring the share security.

User avatar
Cubert
Posts: 1898
Joined: Tue Dec 29, 2015 7:57 pm
Contact:

Re: Habitat Build 1.0.1.5 Official Release Today

Post by Cubert »

Just released 1.0.1.6 correcting this oversight...

Also added to scripts/maintenance folder new Habitat - Test Location Caching Access Script which should allow you to run a script for readiness check.

Post Reply

Return to “Habitat”