Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Buckit last won the day on April 26 2018

Buckit had the most liked content!

About Buckit

  • Rank
    Senior Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi guys, It's been a long while! This week I managed to upgrade PasswordState in my homelab to the most recent build and ran into 8835, which did away with custom SSH scripts. The only reason why I ever needed to make these custom scripts, was because my Linux hosts don't always respond within 10sec. This leads to this well-known error situation: -> http://www.chilkatforum.com/questions/11901/error-reading-public-key-auth-response The error message is caused when the SSH timeout lapses. I would very much appreciate it if the SSH timeout becam
  2. Backing up and restoring to a new host always seems the safest decision to me. But then again, I'm no DBA
  3. You know? I wouldn't mind receiving similar information, because our environment is also under pretty close scrutiny...
  4. Bingo, that'd be it. Thank you very much for your help! I appreciate it. EDIT: Odd, even after syncing the account types, the discovery job still created the duplicate. I'll poke around some more. EDIT 2: Solved... I only re-tested with the acounts for one host and would you believe that it was this particular host that was also mis-registered in AD? :D You were right @Support: the issue was with the type definition.
  5. I've compared the original and the duplicate discovered objects. Up until yesterday there were more differences, but right now the only differences are: * Description: their description is wildly different * Account Type: Linux vs CentOS * Password List: the original is in the desired list, while the newly discovered one is in the list I made specially for that purpose called "Newly Discovered". Now, I sincerely hope that the password list is not taken into account into determining whether an account should be imported I can understand that maybe t
  6. I'll get on it right away.. EDIT: Ah darn, I just realized that I cannot show you the screenshots as they contain identifying information for our environment. Can you tell me which exact fields the discovery job uses to determine whether the object in question already exists? While waiting for you, I'll try and poke through the code to see if I can't find my answer :)
  7. Hi guys, In our environment we have a bunch of Unixen. When spinning up new hosts we frequently quickly add the host and its accounts manually into PasswordState. However, we've then noticed that the account discovery jobs creates a duplicate of the accounts in question. Is there a way to prevent this? * We've set up the object names to match the formating that the discovery job would add. * The identical username is used. * The object is linked to the exact same host. What gives? Is it better to just re-run discovery after upping a new host? I wou
  8. Of course I sincerely hope that @SGauvin and colleagues are actually doing this: first trying the upgrade on Dev/Test/Acc, before moving to Production If I'm reading the linked knowledge base article correctly it's not that there's something actively aborting your connections. It's a matter of the programming language reacting to an error and aborting the thread by itself to handle the error. https://docs.microsoft.com/en-us/dotnet/api/system.web.httpresponse.end?redirectedfrom=MSDN&view=netframework-4.7.2#System_Web_HttpResponse_End
  9. To further demystify FreeIPA for @support: it really is plain LDAP as a directory, with Kerberos authentication and which has a bunch of management tools added onto it. Quite literally RedHat's answer to Active Directory. To further complicate matters there's also RedHat's Idm (Identity Manager), which is mostly similar but a paid-for product. What @wkleinhenz, @Sarge and myself would be looking for, is host and account discovery inside the respective LDAP OU's. Better yet if you make it configurable All in all it would be very similar to how you handle AD discovery, with a few tw
  10. @Sarge: Oof, that's a shame. Sorry to hear that! I'm currently running a PoC to try out a few logging platforms, and am definitely looking to push one through in the next two months. Ahh that's cool! For now I'm on a release from two months ago though, but I'm looking forward to the new features!
  11. I'm currently fighting the syslog feed myself, putting it into Graylog (like @Sarge). In our case, I'm running into the issue that the default syslog parser reads the timestamp as the source name, leading to a large amount of different sources (instead of the single Passwordstate), with thousands of messages all appearing at 01:14:34 (for example).
  12. I was using the latter link, as that's the one that was shown in the error message of the failed upgrade. I'd started the upgrade, which failed in properly downloading the required file. The error message informed me to try again, or to download https://www.clickstudios.com.au/downloads/passwordstate_upgrade.zip . So I guess that path's still hard-coded into some parts of PasswordState. Might I suggest you change those Anywho, mystery solved :P
  13. Ooofff, it's been downloading for six hours now, sitting at 113/180MB. That's throughput from fifteen years ago
  14. Hi guys, I'm working on upgrading my DEV/TEST bed and I've noticed horrible download speeds on the upgrade package. I've snagged the URL from the upgrade process which points at passwordstate_upgrade.zip. This 180MB file will take all of three hours to download. O_O Is this a CDN issue? I'm grabbing it with my usual Macbook, on my normal network which works fine otherwise.
  • Create New...