yes, but I should not worry about those ports, when I use the prebuit tool from neo4j google app right.. I did not make any changes in my own. yes I will see how I can get through this debug log to find out.. I really have to appreciate that you have been extremely helpful all these days. Thank you
@david_allen, I was able to resolve my cluster backup and restore issue. It was access permission that caused the issue for clusters not to form after restoring the graph.db. on google deployed cluster, in order to perform the backup and restore we need to be a neo4j user, I was trying as user that created from the VM. Since that's how the cluster initially starts.
I have a quick question, what would be the password for neo4j user? on those clusters. I have to sudo su neo4j to skip the password.
thank you
The password for the neo4j user is given in the deployment manager output. Go check your deployment, check the output tab and you should see it there.
What else did you fix? Please post your solution so others can benefit. :)
Issue I had with reforming the cluster after restoring the backup of graph.db file, its because of I was trying do backup and restore as user account got created on google, when the cluster got deployed. and graph.db seems to be only accessed through neo4j user account. after switching as neo4j user I was able to reform the cluster after backup and restore. but I still wonder, why it was not configured for google user account to perform the backup and restore.?
1 Like
"Google user account" here is tricky. There are user accounts, and then there are delegated service accounts, which is a big difference. Delegated service accounts tend to have minimal permissions, only what you grant them. When you log in and you're using your permissions, this is different than when you're running automated processes. It's common to have to create service accounts for particular maintenance tasks (like backup and restore) and then to need to grant them various scopes of authority to access resources.
As an example, on google cloud, if you log into a freshly created VM that you created with your own user ID, you'll find that the tools are there to copy data back/forth to google storage, but they won't work. Because the VM itself is running under service account privileges, and they start default without access to your google storage buckets. So then for these administrative operations, you have two choices:
- Use the built-in service account and elevate its permissions
- Auth using a different service account that has the permissions in the CLI, and use that.
These permissioning issues are pretty pervasive with cloud deployment tools because they generally give you the least possible permissions in order to prevent security problems. They actively want you to explicitly grant permission for most things you do.