<p>gsutil n'utilise pas les détails gcloug oauth</p>

L'installation de pip et l'installation de gcloud sont distinctes l'une de l'autre. Si vous utilisez l'installation pip, alors gsutil config configurera votre fichier .boto. Mais si vous utilisez une installation gcloud, alors gcloud auth login doit être utilisé. Tu as l'air de mélanger les deux configurations ? Pourriez-vous essayer les étapes suivantes :

1. Supprimer /Users/domster83/.boto
2. Courez gcloud auth login
3. Exécutez gsutil

J'avais complètement désinstallé gsutil via pip et supprimé le fichier .boto avant d'installer le sdk standard.

Le 2 août 2016, à 20h01, thobrla [email protected] a écrit :

L'installation de pip et l'installation de gcloud sont distinctes l'une de l'autre. Si vous utilisez l'installation pip, gsutil config configurera votre fichier .boto. Mais si vous utilisez une installation gcloud, la connexion auth gcloud doit être utilisée. Tu as l'air de mélanger les deux configurations ? Pourriez-vous essayer les étapes suivantes :

1. Supprimer /Users/domster83/.boto
2. Exécutez la connexion d'authentification gcloud
3. Exécutez gsutil

—
Vous recevez ceci parce que vous êtes l'auteur du fil.
Répondez directement à cet e-mail, consultez-le sur GitHub ou désactivez le fil de discussion.

Donc, gsutil version -l affiche-t-il maintenant un chemin de configuration avec un fichier .boto dans .config/gcloud ?

@thobrla ah ! Non, mais vous m'avez aidé à comprendre. Bien que cela ressemble à un bug.
Actuellement, cela produit

gsutil version: 4.19
checksum: 67da5fbdef140f1663fbb11e96bb9f90 (OK)
boto version: 2.39.0
python version: 2.7.12 (default, Jun 29 2016, 14:05:02) [GCC 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.31)]
OS: Darwin 16.0.0
multiprocessing available: True
using cloud sdk: True
config path: /Users/domster83/.boto
gsutil path: /Users/domster83/google-cloud-sdk/platform/gsutil/gsutil
compiled crcmod: True
installed via package manager: False
editable install: False

Et ça m'a fait penser à moi ENV. J'avais BOTO_CONFIG défini dans mon bash_profile comme

export BOTO_CONFIG="$HOME/.boto"

Ce qui m'a donné BOTO_CONFIG=/Users/domster83/.boto comme ENV VAR.
Si je commente cette ligne et recharge mon terminal, sans l'ENV VAR j'obtiens

gsutil version: 4.19
checksum: 67da5fbdef140f1663fbb11e96bb9f90 (OK)
boto version: 2.39.0
python version: 2.7.12 (default, Jun 29 2016, 14:05:02) [GCC 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.31)]
OS: Darwin 16.0.0
multiprocessing available: True
using cloud sdk: True
config path: /Users/domster83/.boto
gsutil path: /Users/domster83/google-cloud-sdk/platform/gsutil/gsutil
compiled crcmod: True
installed via package manager: False
editable install: False

MAIS .... gsutil fonctionne maintenant. Il montre le même chemin de configuration, même fichier cependant. Ni l'un ni l'autre ne sont .config/gcloud

Je pense qu'il y a un bogue ici - lors de la recherche du chemin de configuration, nous nous arrêtons lors de la découverte du premier fichier valide, mais plusieurs fichiers peuvent être spécifiés via la variable BOTO_PATH (c'est ainsi que gcloud transmet les informations d'identification à gsutil).

Je crois que je rencontre également ce problème de fichier de configuration. Je souhaite définir use_magicfile dans un dépôt contrôlé par version plutôt que dans un fichier de configuration global, afin de servir des pages Web sans extensions .html .

Si je définis des variables BOTO_CONFIG ou BOTO_PATH , je perds les informations d'identification que j'ai définies avec gcloud auth login . Un gsutil rsync donne :

401 Anonymous users does not have storage.objects.list access to bucket foo.example.com.

Notez que cela se produit même si BOTO_CONFIG pointe vers /home/blah/.boto

En regardant le code boto.pyami.config, nous ne chargeons plusieurs fichiers .boto que si :

1. BOTO_CONFIG n'est pas défini dans vos variables d'environnement
2. BOTO_PATH est défini dans vos variables d'environnement

Donc, afin d'utiliser plusieurs fichiers de configuration, vous voudrez ajouter le chemin de votre configuration .boto spécifique au dépôt (qui, d'après votre description ci-dessus, ne devrait contenir que les options de configuration que j'ai montrées ci-dessous) à l'ensemble de chemins dans votre variable BOTO_PATH. Notez qu'ils sont chargés dans l'ordre, vous devez donc ajouter ce chemin plutôt que de le préfixer.

[GSUtil]
use_magicfile = True

J'ai testé cela moi-même avec gsutil v4.22 en remplaçant l'option default_project_id dans mon deuxième fichier .boto, en exécutant export BOTH_PATH=/path/to/second/boto/config , puis en exécutant gsutil ls (le binaire gsutil inclus avec le gcloud SDK, qui utilise un script wrapper pour définir la variable d'environnement BOTO_PATH) pour s'assurer qu'il répertorie les buckets dans le projet par défaut spécifié par ma deuxième configuration.

En ce qui concerne le commentaire de thobrla , je vais obtenir un correctif pour m'assurer que lorsque les conditions 1 et 2 ci-dessus sont vraies, nous affichons tous les fichiers de configuration lisibles dans la sortie pour gsutil version -l .

Merci @houglum ! Je vais essayer.

Pas de chance :

~$ head ~/.boto
# This file contains credentials and other configuration information needed
# by the boto library, used by gsutil. You can edit this file (e.g., to add
# credentials) but be careful not to mis-edit any of the variable names (like
# "gs_access_key_id") or remove important markers (like the "[Credentials]" and
# "[Boto]" section delimiters).
#
# This file was created by gsutil version 4.22 at 2017-02-26 10:29:13.
#
# You can create additional configuration files by running
# gsutil config [options] [-o <config-file>]
~$ cat /Users/foo/bar/.boto
[GSUtil]
use_magicfile = True
~$ unset BOTO_PATH
~$ gsutil ls
~$ echo $?
0
~$ export BOTO_PATH="/Users/foo/.boto"
~$ gsutil ls
ServiceException: 401 Anonymous users does not have storage.buckets.list access to project 9999999.
~$ export BOTO_PATH="/Users/foo/.boto:/Users/foo/bar/.boto"
~$ gsutil ls
ServiceException: 401 Anonymous users does not have storage.buckets.list access to project 9999999.
~$ export BOTO_PATH="/Users/foo/bar/.boto"
~$ gsutil ls
ServiceException: 401 Anonymous users does not have storage.buckets.list access to project 9999999.

Oh hé, je peux tout à fait reproduire cela aujourd'hui. Je pense que le shell que j'utilisais hier avait des alias restants pour gsutil, de sorte que j'invoquais une version non gcloud. Désolé pour la confusion :)

Quoi qu'il en soit, en réalisant cela, j'ai compris qu'il s'agissait d'un bogue avec le script d'amorçage gsutil utilisé par gcloud, /path-to-cloud-sdk/bin/bootstrapping/gsutil.py. Voici l'extrait coupable :

    # We construct a BOTO_PATH that tacks the refresh token config
    # on the end.
    if boto_config:
      boto_path = os.pathsep.join([boto_config, gsutil_path])
    elif boto_path:
      boto_path = os.pathsep.join([boto_path, gsutil_path])
    else:
      path_parts = ['/etc/boto.cfg',
                    os.path.expanduser(os.path.join('~', '.boto')),
                    gsutil_path]
      boto_path = os.pathsep.join(path_parts)

      if 'BOTO_CONFIG' in os.environ:
        del os.environ['BOTO_CONFIG']
      os.environ['BOTO_PATH'] = boto_path

Cette dernière ligne doit être décalée vers la gauche d'un niveau d'indentation afin qu'elle soit appliquée quels que soient les prédicats ci-dessus qui soient vrais. Je vais informer nos gens de gcloud afin que nous puissions résoudre ce problème.

(En outre, WRT mon commentaire précédent, il semble que le script gcloud transmette son projet par défaut configuré en tant qu'option de niveau supérieur, c'est-à-dire "-o 'GSUtil:default_project_id=...'", donc on ne peut pas écraser le projet par défaut en utilisant un fichier .boto local.)

Ce correctif, comme indiqué ci-dessus, est inclus dans la version la plus récente de gcloud, et ce02232 corrige le problème de liste de configuration. Fermant ça.