Hopefully I don't sound too stupid asking this. My wife and I run a small business out of our home. We want to share the accounting data, but I'm at another location often. We use a PC version of Sage Peachtree Premium Accounting that has networking capabilities, so the data files can be stored in a common place. Is it possible to share this file using something like Google Cloud Storage?
Google Drive is certainly the cheaper option as it is optimized for consumer usage patterns. Google Cloud Storage is optimized for applications that demand highly available and replicated storage with strong global consistency.
Here are a few ways that Google Cloud Storage attempts to improve team collaboration:
Resources are owned by a project team composed of multiple people.
It is possible to share files with a group.
It is possible to change the default acl applied to new objects.
Collaborate with a team
Each bucket is owned by a project and by default everyone on your team can read new objects upload to those buckets.
You manage the people on your team in the following manner:
Go to https://code.google.com/apis/console
Click on teams on the sidebar.
Add the email addresses of other people you want to collaborate with.
Use the drop-down list to give them more permissions.
Use the x to remove team members.
Permissions are concentric:
Everyone with can view access will be able to read files that do not specify an acl.
Everyone with can edit access will also be able to create and delete buckets as well as upload new objects.
Everyone with is owner access will also be able to add other viewers, editors and owners.
Share to a Google Group
Google Cloud Storage allows you to share files with a Google group. User gain access to these files when you add them to the group and lose access when you remove them from the group.
First download the objects acl:
gsutil getacl gs://bucket/obj > acl.xml
vim acl.xml
Now add the following acl entry inside the <Entries/> tag:
<Entry>
<Scope type="GroupByEmail">
<!-- Give everyone in the gs-discussion group READ access. -->
<EmailAddress>gs-discussion#googlegroups.com</EmailAddress>
</Scope>
<Permission>READ</Permission>
</Entry>
Now update the acl:
gsutil setacl acl.xml gs://bucket/obj
See the online documentation for further information about access control https://developers.google.com/storage/docs/accesscontrol#applyacls
You can create a Google group at google.com/groups
Change the default object acl
By default everyone on the team can read objects you upload. However you can configure this to be more or less permissive. You could make objects publicly-readable by default or only viewable by the owner and a Google group.
Changing the default object acl is similar to changing object acls. Just use the getdefacl and setdefacl commands.
Some predefined configurations do not require editing an xml file:
# Team members can view new objects.
gsutil setdefacl project-private gs://bucket
# Anonymous internet users can view new objects.
gsutil setdefacl public-read gs://bucket
Otherwise you can edit the acl xml:
gsutil getdefacl gs://bucket > def_acl.xml
vim def_acl.xml
# Add whichever UserByEmail, GroupByEmail, AllUsers, etc grants you want.
gsutil setdefacl def_acl.xml gs://bucket
New objects apply the default object acl:
gsutil cp foo gs://bucket # This object will receive the def_acl.xml acls.
It is easy to override the default object acl with a predefined acl for a particular object:
# Ignore the default acl. Use public-read.
gsutil cp -a public-read foo gs://bucket
The full list of predefined acls is available at developers.google.com/storage/docs/accesscontrol#extension
Google Cloud Storage is probably overkill for what you're talking about. Cloud Storage is something web developers use to deliver assets like images, videos, and documents to a large number of users around the world.
However something like Google Drive or Dropbox would probably work well for this. If you both have Gmail accounts then Google Drive is a natural choice. Both of these solutions have a service which runs on each PC and automatically syncs changed files in a specified folder to all other computers using that folder.
So if one of you makes changes to the file, it will show up in the other location automatically. However the real question is how your software will handle this. I'm not familiar with Peachtree Accounting but it probably isn't possible for you to both be making changes at the same time, unless the software is specifically designed for that use case.
If you can post a link or description for the "networking capabilities" (that is a rather vague term on its own) it may be possible to tell for sure.
Related
I want to give a service account read-only access to every bucket in my project. What is the best practice for doing this?
The answers here suggest one of:
creating a custom IAM policy
assigning the Legacy Bucket Viewer role on each bucket
using ACLs to allow bucket.get access
None of these seem ideal to me because:
Giving read-only access seems too common a need to require a custom policy
Putting "Legacy" in the name makes it seem like this permission will be retired relatively soon and any new buckets will require modification
Google recommends IAM over ACL and any new buckets will require modification
Is there some way to avoid the bucket.get requirement and still access objects in the bucket? Or is there another method for providing access that I don't know about?
The closest pre-built role is Object Viewer. This allows listing and reading objects. It doesn't include storage.buckets.get permission, but this is not commonly needed - messing with bucket metadata is really an administrative function. It also doesn't include storage.buckets.list which is a bit more commonly needed but is still not part of normal usage patterns for GCS - generally when designing an app you have a fixed number of buckets for specific purposes, so listing is not useful.
If you really do want to give a service account bucket list and get permission, you will have to create a custom role on the project. This is pretty easy, you can do it with:
gcloud iam roles create StorageViewerLister --project=$YOUR_POJECT --permissions=storage.objects.get,storage.objects.list,storage.buckets.get,storage.buckets.list
gcloud projects add-iam-policy-binding $YOUR_PROJECT --member=$YOUR_SERVICE_ACCOUNT --role=StorageViewerLister
So I have a small company with plenty of documents and I want to set up an archiving system. I have several employees with different levels of permissions to access the files on the server. This will serve as an archive system plus a management system, as employees can read and write files (depending on the permission) for a certain project, then the admin can prevent access to certain directory (i.e. project).
So after some research I think the best idea is to have a cloud-based NAS in which a user can have locally by giving the correct username and password. Then a software will access these files (which are now local) and can display some data (e.g. project progress, minutes of meetings), or the user can access the files directly.
Does any of this make sense? I mean is that what NAS can actually do and can it be done on the cloud? and can users access the file system (with restrictions) given username and password (much like if it were a network). Is there a better alternative for my purposes?
To the best of my knowledge, I can, instead, create a software that accesses the cloud directly, but how can I get the users to write files and be stored on the cloud? won't that be more complicated to implement? Can I use an RDMS for it? I've used it before but never for files.
If I understand your use case correctly, all you really want is to have access to different files for different roles within your company, is this correct?
To the best of my knowledge, I believe that Google provide corporate accounts which are quite affordable which should have access control schemes suiting what you need (after all, storing files on scaling storage, with various access controls in an offsite location and with redundancy is partly what the cloud is for).
If not, or if this solution isn't appealing to you and you would prefer to use your NAS, the best way to do this would be to use Google's Backup and Sync application (you can download this by clicking the cog icon on Drive and selecting it). If you install and run this on an admin computer that is always on (and always connected (mounted) with your NAS), you can set a root folder on the NAS as your Drive sync folder. Any files added to this folder will be uploaded to Drive, and any added to Drive will be automatically downloaded. After this you can configure the access control on the NAS using various user accounts and roles, and have each employee mount the store using their own credentials, revealing only the files they have access to.
I would like to specify different default ACL levels for two different folders in the same Google Cloud storage bucket. Is this even possible, or is there perhaps some workaround available?
It seems to be possible retroactively specify different ACL levels for different folders using the gsutil acl command, whereas it is only possible to use the gsutil defacl command on the entire bucket. Correct?
Some potential workarounds I've been brainstorming, but not found any support for yet:
Set each files specific ACL from the client-side (iOS/Android) when it is first uploaded.
Have a Cloud Function listen for new file uploads and then modify it's ACL accordingly.
Again, I have not found any clues in the official documentation towards implementing any of the above solutions, so any pointers would be greatly appreciated. Thanks in advance!
Right now, ACLs can only be applied to individual objects, and IAM policies can only be applied to entire buckets or individual objects.
Your two proposed solutions are both reasonable but both have drawbacks. The first solution would be best, but only if you trust the iOS user to set good permissions. The client could potentially set different permissions. That's not necessarily a problem, since presumably the client already has the data and, if they were malicious, could already share it anywhere it wanted to, but it's something to be aware of.
The second solution is also fine, but there's a very small window of time wherein the object's ACLs would be incorrect. That may also not be a problem for you.
One nice variation might be to have users upload the objects to a "staging" bucket, and then have a Cloud Function respond to that upload by moving the object to its production location with the correct ACL, then delete the staged version.
I am looking to develop a Chrome Packaged App that will (at a very simple level) provide a dynamic form filling UI - but allow users to attach large attachments to the forms (could be upwards of 10 files of 10MB each). I would like to have the ability to save and share the form data and the attachment via Google Drive. The forms will be completed collaboratively by multiple team members who also need to all see the attachments. Imagine a form front-end/metadata that sits on top of a shared Google Drive folder...
I have read the documentation, and learnt that the syncFileSystem API is not intended for use for general and/or large files to be stored in Google Drive, but rather for small configuration data.
I then looked at the fileSytem API - hoping that I could include the Sandboxed folder for the app in the folders that the Google Drive Client App (so that the files get synced automatically) - but it doesn't look like the sandbox is meant to be accessed externally.
My current thinking is to recreate a windows explorer type UI in the packaged app (can use drag and drop) - then store the files in the sandbox using the fileSystem API. I can reuse the code from the Google Drive sample packaged app to implement cloud syncing. Good idea?
Two questions stem from this:
How persistent is the fileSystem API. The documentation mentions that the user can purge all stored files - is this done through 'clearing all browser history' ? In which case they could very easily accidentally wipe many hundreds of MB of useful information that I am storing in the packaged app.
I have read that you can use a 3rd party authentication services (which I want to do). If I use a non-Google account to authenticate my users, how would the Google Drive authentication work ? Would I be able to use a different Google account to perform the cloud storage (i.e. unrelated to the actual end user, who may or may not have a Google account already - which may already be signed in)
It seems like waiting for this https://code.google.com/p/chromium/issues/detail?id=148486 (getting read access to non-sandbox directories) would be the easiest way forward.
I don't think clearing browser history deletes temporary sandbox filesystem files, they're supposed to be sort of automatically garbage collected when space is required. It would make sense if that were another checkbox in the "Clear browsing data" section of chrome's options. Perhaps that would make the answer to your first question more clear :-)
The second point, I am not sure how to do this, but it looks like you have already figured out something? At least that's what this page https://groups.google.com/a/chromium.org/forum/#!topic/chromium-apps/hOYu75Cv0AE seems to indicate
I would like my customer to drop a file in my bucket. Reading this document https://developers.google.com/storage/docs/collaboration I understood that my customer will have an additional step of editing ACL of the file he loads before I can process the file. This is very inconvenient since I do not want to trouble my customer with overly technical matters. Is there a user friendly alternative?
For the time being I had to create a specific customer project, make a customer rep a team member with "edit" access to the project. This scenario had the unwanted side effect of granting default access to other services in the project. I had to go through the various services and find ways to limit the customer access.
You can specify a default object ACL for your bucket to automate this process. Use the gsutil setdefacl command to do this.