Jump to content

Internet-less upgrade method still needs internet access


jimmy

Recommended Posts

From the Upgrade_Instructions.pdf file, I am trying to do the part:

In-Place Upgrade Instructions without Internet Connectivity

 

According to this:

I've changed the DB with the 8.3 version and build 8325, downloaded the passwordstate_upgrade.zip file to the passwordstate\upgrade folder, disabled the automatic backup (I have a vmware snapshot), entered maintenance mode, restarted the service, but when I go to the upgrade (Administration / Backups and Upgrades / Upgrade now / Begin Upgrade) the system says that it needs connectivity to the clickstudio's website.

(Also, the upgrade is not shown on top after the current version)

 

To be precise, the button changes in testing download and then it says In order to perform an inplace-upgrade of paswordstate, your passwordstate install must be able to query click studio's web site.

 

I guess the system does not see that I placed the zip-file into the upgrade folder?

Link to comment
Share on other sites

Hi Jimmy,

 

Sorry you're having some issues with this. I've just done some testing, but cannot seem to reproduce this - I disabled the network card for the test.

 

We use the method of placing the passwordstate_upgrade.zip file in the /upgrades folder for every release, as we test the upgrade process before releasing - obviously we don't want to download from the Internet in this instance, as we haven't uploaded the new file yet.

 

I've just done a code review, and it's possible that there is a different error which is causing our code to redirect to this page you are seeing. Can you try the following:

 

1. Make sure the Passwordstate folder, and everything beneath it, has Modify or Full NTFS permissions for the NETWORK SERVICE account

2. Now use the instructions '5. Manual Upgrade Instructions' in the following document - https://www.clickstudios.com.au/downloads/version8/Upgrade_Instructions.pdf

 

Regards

Click Studios

Link to comment
Share on other sites

6 hours ago, support said:

1. Make sure the Passwordstate folder, and everything beneath it, has Modify or Full NTFS permissions for the NETWORK SERVICE account

 

Yikes, you sure about that? I'm not overly familiar with Windows security, so I could be wrong, but to me that reads like you''re giving your web application full write access to its own source files. That's not usually something you want, right?

 

"Hellooooo LFI vulnerabilities!" - Yakko Warner (probably)

 

Is this a temporary change that can be undone when the upgrade has completed?

 

Link to comment
Share on other sites

Hi Buckit,

 

Our In-Place Upgrade feature requires you to specify an account which has permissions to overwrite the files in the Passwordstate folder - so we "impersonate" this account in code to update files.

 

I was suggested to look at the NTFS permissions, as this might explain Jimmy's error.

 

I would have thought using the same password across many hosts would be worse than NTFS permissions in compiled code ;)

Regards

Click Studios

Link to comment
Share on other sites

Touché! ;)

 

Sorry, I did not mean to be patronizing, or whatever the word that applies may be. Snarky? Dickish? Either way, I didn't mean to do that :)

 

The methods you describe sound pretty solid! Sounds a bit like sudo-but-on-windows. As I said, I'm still a Windows rookie.

Link to comment
Share on other sites

7 hours ago, support said:

Sorry you're having some issues with this. I've just done some testing, but cannot seem to reproduce this - I disabled the network card for the test.

 

 

1. Make sure the Passwordstate folder, and everything beneath it, has Modify or Full NTFS permissions for the NETWORK SERVICE account

 

 

Our VM does have a network so it probably "thinks" that internet is reachable?  It's just that the default gateway does no internet.

 

Wouldn't those permissions be a large security risk?

This install is in a no-internet zone because it's a very secure company...

 

43 minutes ago, support said:

Our In-Place Upgrade feature requires you to specify an account which has permissions to overwrite the files in the Passwordstate folder - so we "impersonate" this account in code to update files.

 

I was suggested to look at the NTFS permissions, as this might explain Jimmy's error.

 

I would have thought using the same password across many hosts would be worse than NTFS permissions in compiled code ;)

Regards

Click Studios

I doon't understand what you mean with "specify an account"? I can only specify an account for the backup, not for the install. Or am I missing something?

Link to comment
Share on other sites

Hi Jimmy,

 

Yes, I meant the backup account in this instance.

 

With our pages, they are all pre-compiled code, with some files being obfuscated. So there are no security concerns over these NTFS permissions.

Let us know if the manual upgrade method works out for you, and we'll do some further testing to see if we can replicate your issue.

 

Regards

Click Studios

Link to comment
Share on other sites

11 minutes ago, support said:

Hi Jimmy,

 

Yes, I meant the backup account in this instance.

 

With our pages, they are all pre-compiled code, with some files being obfuscated. So there are no security concerns over these NTFS permissions.

Let us know if the manual upgrade method works out for you, and we'll do some further testing to see if we can replicate your issue.

 

Regards

Click Studios

I guess we are now talking about two different things? We don't need the backup because we create a snapshot (and have a VM backup).

What would the backup account have to do with the ntfs permissions for upgrading without a backup?

Link to comment
Share on other sites

Hi Jimmy,

 

During the upgrade, we need to stop the Passwordstate Windows Service, extract and overwrite all the files, then restart the Passwordstate Windows Service. This is what we use the backup account for - on the screen Administration -> Backups and Upgrades.

If you don't want to configure this, then you can instead use that Manual Upgrade method I mentioned.

 

I hope this clarifies.

Regards

Click Studios

Link to comment
Share on other sites

10 hours ago, support said:

During the upgrade...

It looks to me that the problem is one step before that. It's on the step "seeing the upgrade".

When I alter the database, place the zipfile and go into the web-interface, the update should be shown at the top of the page. In our case, it is not.

So that's probably why it wants to go to the internet when attempting to upgrade, it does not "recognize" that the upgrade is present locally.

 

Also, when I enter a username/password the Test Permissions fails. Either with my personal (admin-like) domain account and with our domain-admin account.   I enter it with domain\username, and the path is just d:\backup.  The permissions are "Authenticated users":M(RWL)

Link to comment
Share on other sites

Hi Jimmy,

 

I'm not sure what build you're upgrading from, but new Build Numbers are not shown at the top of the screen anymore - they will be added into the Notification Center on a schedule.

 

If you go to the screen Administration -> Backups and Upgrades, and click on the 'Upgrade Now' button, you will see the NewBuildNo change being reported on this screen.

 

Regards

Click Studios

Link to comment
Share on other sites

Current build is 8180.

Yes, on administration-> backups and upgrades, it shows the current and latest (8325).

So that seems to be fine then (except for the upgrade pdf that tells me to check the top of the screen).

 

But then next, any attempt to enter credentials keeps failing on the Test Permissions button. I have D:\passwordstate as the path and Full control for the Domain Administrator, NETWORK SERVICE, local administrators, and the MSSQL$SQLEXPRESS user.  The folder is new and empty. The result is the same when I share it (with full share permissions) and use the \\computername\sharename. I tested it with the domain-admin account and my personal admin account.

 

When I click Backup Now -> Start backup, it says Please check the account you've specified has appropiate access rights to restart the passwordstate service.

However, I am currently logged in as that same user and I am able to restart the service.

 

(Finally, at Upgrade Now -> Begin Upgrade, the button changes to Test Downloading, which assumes it want to download instead of using the local file.)

Link to comment
Share on other sites

Sorry, addition:

The Start backup error was because at that point I was doing tests with an intentionally wrong account.

With the domain admin, it says: Backup error detected - Object reference not set to an instance of an object.

(I did restart the service after making changes to the backup settings and account)

Link to comment
Share on other sites

Sorry Jimmy - we'll need to correct that reference of the message at the top of the screen, as it is out dated - we didn't realise it was still in there.

 

If you are wanting to configure this backup account, we have whats fully required in the Security Administrators manual. You can find this under the Help Menu, and then look in the Backups and Upgrades section.

 

Did you want to do the manual upgrade for now, and then you can explore the backup account permissions required after?

 

Regards

Click Studios

Link to comment
Share on other sites

Can we go back one step.

The symptom it that the program wants to go to the internet instead of using the locally placed file. And now we are discussing backups, accounts, permissions and stuff. Isn't there a totally different reason why it tries to download a file that is already there??

 

 

And just to make sure, we're not talking about the backup account but the (same) account needed for the upgrade.

I just tested the backup to show that there are probably related issues. We don't actually need the backup, I'm just going through that all because you explained that the account settings are also needed for the upgrade...

 

So if we can skip the backup-issues (unless they help solving the upgrade issue), I'm fine with that.

 

But.. Do you really want me to go through a 180pg document just to solve an issue with a 1/2pg upgrade description?

I did check what you mentioned before, the NETWORK SERVICE has (F) on the passwordstate folder and subfolders and so does it on the backupfolder. The account that I use for the upgrade is the domain admin which I guess should just be enough?

 

From that manual, I found at least:

The path to where you would like to store the backups - please use UNC naming conventions
here, not a literal path such as c:\backups
·
Username and Password required for the backup (below in this document is an explanation of
the permissions required)

 

So I am now using \\computername\sharename which are accessible.

 

Then it says:

To allow backups to work through the Passwordstate web interface, you will need to specify an
account (domain or Windows account), which has the following permissions:
·
Permissions to write to the Backup path you’ve specified
·
Permissions to stop and start the Passwordstate Windows Service on the web server
·
Permissions to write to the Passwordstate folder on your web server

 

Which are all correct.

 

Now we come to this:

 

In addition to this, you must configure the SQL Server service to use a domain or Windows account
which has permissions to also write to the Backup Path.

 

We did a normal install and that installed the MSSQL Express instance.

That has installed it with (default?) NTService\MSSQL$SQLEXPRESS account.

Since this is going to run in a very secure environment (that's why we cannot update from the internet), are you positive that we need a Domain account there?

Is there a way to skip this, just because this is only for the backup-part and not for the upgrade??

 

I also went through the Automatic Backup Troubleshooting part, where I also do not see any reason for an issue.

 

Link to comment
Share on other sites

Hi Jimmy,

 

I pointed you to the correct part of the Security Administrator's manual - I certainly didn't expect you to read all 180 pages.

 

For SQL Server, if you want Passwordstate to backup the database, then yes this is required - either for scheduled backups, or backups just prior to upgrades. Or you can check the option to say you don't want to backup the database, and you can manage this separately yourself.

 

We try and give customers options for these sort of things, and let them decide what's best for their environment. Possibly because this is a "secure" environment, the manual method I outlined might be the best option for you.

 

Regards

Click Studios

Link to comment
Share on other sites

Let's not give up please, as I suggested before this is probably not a security issue but there must be a simple reason why it tries to download a file that is already there?  Can we continue on that?  Why does it want to access the internet while we follow the procedure for upgrading without internet?

 

From Windows- and permissions perspective there is nothing special about this machine, it's just that we cannot just change the current SQL account, especially because you now say that we do not need that if we do not need the backup.

 

Link to comment
Share on other sites

In the meantime I've been testing the other way around: unplug the NIC.

Now the button keeps saying "testing download..." forever (or at least for 30 minutes until I terminated it).

So there seems to be some difference but still not like it works at your side.

 

When the NIC is disconnected I see Windows Events "An error has occured executing the call 'SecurityGroupExists'. The server is not operational."  Perhaps this is because the ADDS is then also unreachable.

With te NIC connected I see nothing in the eventlog.

 

To make sure it really attempts to access internet, I added www.clickstudios.com.au to the hosts file, pointing to 127.0.0.1. This causes the upgrade now to fail even faster. That proves that it does do a call to www.clickstudios.com.au at a point where it should not.

(I double checked the permissions on the zip-file, and also extracted it once to verify that it's not corrupted)

 

I have created a quick-and-dirty webserver replacement of http and https for www.cliskstudios.com.ca to have a bit of logging, and I see that it requests /NewBuildInfo.xml (plain over port 80?).

Perhaps then you know what is going on? (it's not the upgrade zipfile but an xml)

 

Tomorrow I won't be able to change or test anything, but please feel free to keep me informed (I am able to reach this site).

Link to comment
Share on other sites

1 hour ago, jimmy said:

I have created a quick-and-dirty webserver replacement of http and https for www.cliskstudios.com.ca to have a bit of logging, and I see that it requests /NewBuildInfo.xml (plain over port 80?).

 

Great thinking!

Link to comment
Share on other sites

Hi Jimmy,

 

Thanks for your patience with this, and we do need to apologize - this is an issue with our code, checking that xml file as you mentioned. I'm not sure why I didn't see this in testing - possibly it was cached somewhere.

 

We've fixed this for the next release, which means you will obviously need to perform a manual upgrade when this new release is available. We're not sure when the next release is yet, but it could be 2 to 4 weeks again.

 

Again, thanks for your patience, and sorry again.

Regards

Click Studios

Link to comment
Share on other sites

So that's good news twice!

For me because I now know that I am not doing it wrong, for you because you can now fix a bug.

I will have to do my work double now, because I need to write a procedure to do the update process from dev/test, via acc, to prod. Which now means I have to describe both the manual and the "regular" internet disconnected upgrade method. But at least I now know what to do.

Thank you for all the effort!

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...