Pliki konfiguracyjne dla polecenia s3cmd w NSIS
s3cmd może uzyskać dostęp do zdalnych danych za pomocą protokołu S3. Obejmuje to EODATA repozytorium i przechowywanie obiektów w chmurze NSIS.
Aby połączyć się z magazynem S3, s3cmd używa kilku parametrów, takich jak klucz dostępu, klucz tajny, punkt końcowy S3 i inne. Podczas konfiguracji można wprowadzić te dane interaktywnie, a polecenie zapisuje je w pliku konfiguracyjnym. Plik ten można następnie przekazać do s3cmd podczas wydawania poleceń przy użyciu opisanego połączenia.
Jeśli chcesz korzystać z wielu połączeń z jednej maszyny wirtualnej (np. łącząc się zarówno z repozytorium EODATA, jak i z magazynem obiektów w chmurze NSIS), możesz utworzyć i przechowywać wiele plików konfiguracyjnych - po jednym na połączenie.
Ten artykuł zawiera przykłady tworzenia i zapisywania tych plików konfiguracyjnych w różnych okolicznościach i opisuje niektóre potencjalne problemy, które można napotkać.
Przykłady nie są przeznaczone do sekwencyjnego wykonywania w ramach przepływu pracy; zamiast tego ilustrują różne przypadki użycia operacji s3cmd.
Co będziemy omawiać
Wymagania wstępne
Nr 1 s3cmd zainstalowany
Aby korzystać z s3cmd, należy go najpierw zainstalować. Oto niezbędne informacje:
Jak zainstalować s3cmd w systemie Linux na NSIS
Nr 2 Znajomość korzystania z s3cmd
Aby uruchomić przykłady w dalszej części tego artykułu, konieczne będzie prawidłowe skonfigurowanie s3cmd przy użyciu tego artykułu:
Inicjowanie procesu konfiguracji
Zapisywanie pliku konfiguracyjnego s3cmd to dwuczęściowy proces:
odpowiadając na serię interaktywnych pytań, a następnie
zapisanie odpowiedzi w pliku konfiguracyjnym.
Wykonaj to polecenie
s3cmd -c eodata-config --configure
aby rozpocząć sesję interaktywną. Użytkownik wprowadza dane dla
Public Key - klucz dostępu z warunku wstępnego nr 2.
Secret Key - Twój tajny klucz z warunku wstępnego nr 2.
Domyślny region - USA
Punkt końcowy S3 – s3.waw4-1.cloudferro.com.
Enter new values or accept defaults in brackets with Enter. Refer to user manual for detailed description of all options. Access key and Secret key are your identifiers for Amazon S3. Leave them empty for using the env variables. Access Key: <your EC2 access key> Secret Key: <your EC2 secret key> Default Region [US]: US Use "s3.amazonaws.com" for S3 Endpoint and not modify it to the target Amazon S3. S3 Endpoint [s3.amazonaws.com]: s3.waw4-1.cloudferro.com Use "%(bucket)s.s3.amazonaws.com" to the target Amazon S3. "%(bucket)s" and "%(location)s" vars can be used if the target S3 system supports dns based buckets. DNS-style bucket+hostname:port template for accessing a bucket [%(bucket)s.s3.amazonaws.com]: Encryption password is used to protect your files from reading by unauthorized persons while in transfer to S3 Encryption password: Path to GPG program [/usr/bin/gpg]: When using secure HTTPS protocol all communication with Amazon S3 servers is protected from 3rd party eavesdropping. This method is slower than plain HTTP, and can only be proxied with Python 2.7 or newer Use HTTPS protocol [Yes]: On some networks all internet access must go through a HTTP proxy. Try setting it here if you can't connect to S3 directly HTTP Proxy server name: New settings: Access Key: <your EC2 access key> Secret Key: <your EC2 secret key> Default Region: US S3 Endpoint: s3.waw4-1.cloudferro.com DNS-style bucket+hostname:port template for accessing a bucket: %(bucket)s.s3.amazonaws.com Encryption password: Path to GPG program: /usr/bin/gpg Use HTTPS protocol: True HTTP Proxy server name: HTTP Proxy server port: 0 Test access with supplied credentials? [Y/n] Please wait, attempting to list all buckets... Success. Your access key and secret key worked fine :-) Now verifying that encryption works... Not configured. Never mind. Save settings? [y/N] y Configuration saved to 'eodata-config'
Jeśli jest to pierwsze polecenie wydane dla pliku eodata-config, w sesji interaktywnej nie będzie danych domyślnych.
Aby anulować proces konfiguracji, naciśnij CTRL+C.
Objaśnienie parametrów
Najczęściej używanymi parametrami s3cmd są:
- -c
Określa nazwę i/lub lokalizację pliku konfiguracyjnego (uwaga: pojedynczy myślnik).
- --config
Alternatywa dla -c (uwaga: dwa myślniki).
- --configure
Inicjuje sesję pytań na ekranie i zapisuje odpowiedzi do pliku.
Możesz użyć -c lub --config obok --configure.
Upewnij się, że poprawnie przekazujesz ścieżkę pliku do powłoki, zwracając uwagę na spacje, cudzysłowy lub znaki specjalne.
Miejsce docelowe: plik domyślny
Domyślną lokalizacją pliku konfiguracyjnego s3cmd jest ukryty plik o nazwie .s3cfg znajdujący się w katalogu domowym użytkownika.
Aby sprawdzić swój katalog domowy, użyj
echo $HOME
W systemie Linux katalog domowy to zazwyczaj /home/<nazwa użytkownika>.
Na maszynie wirtualnej hostowanej przez NSIS będzie to zazwyczaj /home/eouser. Zatem plik konfiguracyjny będzie miał postać /home/eouser/.s3cfg.
Aby zainicjować proces konfiguracji przy użyciu domyślnej lokalizacji:
s3cmd --configure
Zabezpieczanie pliku konfiguracyjnego
Po utworzeniu pliku konfiguracyjnego zaleca się zabezpieczenie go poprzez ustawienie odpowiednich uprawnień. Dzięki temu klucze dostępu i klucze tajne nie będą mogły zostać odczytane przez nieautoryzowanych użytkowników.
Przykładowe polecenie zabezpieczające domyślny plik konfiguracyjny:
chmod 600 ~/.s3cfg
To polecenie sprawia, że plik może być odczytywany i zapisywany tylko przez użytkownika.
Miejsce docelowe: plik niestandardowy
Jeśli wybranym miejscem docelowym jest plik niestandardowy, przekaż jego nazwę i/lub lokalizację do polecenia za pomocą parametru -c. Zakończ polecenie za pomocą --configure, aby poinstruować s3cmd do utworzenia pliku.
Przykłady:
Plik o nazwie object-storage-access w bieżącym katalogu roboczym.
s3cmd -c object-storage-access --configure
Plik o nazwie eodata-access w katalogu /home/eouser/
s3cmd -c /home/eouser/eodata-access --configure
Plik o nazwie object-storage-access znajdujący się w katalogu nadrzędnym bieżącego katalogu roboczego.
s3cmd -c ../object-storage-access --configure
Ponownie, jeśli zapisujesz plik konfiguracyjny poza domyślną lokalizacją (np. jako /home/eouser/eodata-access), powinieneś również ustawić odpowiednie uprawnienia do pliku, aby go chronić.
Przykładowe polecenie:
chmod 600 /home/eouser/eodata-access
Dzięki temu klucze dostępu i klucze tajne pozostają bezpieczne, podobnie jak w przypadku domyślnego pliku .s3cfg.
Używanie --configure na istniejącym pliku
Kiedy używasz --configure, s3cmd będzie działać na pliku:
Jeśli -c lub --config zostaną pominięte, użyje domyślnej lokalizacji.
Jeśli podano -c lub --config, użyje podanego pliku.
Jeśli plik konfiguracyjny taki jak eodata-config już istnieje, aplikacja zaproponuje wartości domyślne i zaakceptuje je po naciśnięciu klawisza Enter.
Istniejący i prawidłowy plik konfiguracyjny s3cmd
Jeśli:
przekazać istniejący prawidłowy plik konfiguracyjny s3cmd,
użyj --configure, i
zatwierdzenie zapisu po zakończeniu sesji,
odpowiedzi zaktualizują istniejącą konfigurację.
Jeśli anulujesz przed zapisaniem, oryginalna konfiguracja pozostanie niezmieniona.
Istniejący plik, ale nie prawidłowy plik konfiguracyjny s3cmd
Jeśli:
przekazać istniejący plik, który nie jest prawidłowym plikiem konfiguracyjnym s3cmd, oraz
użyj --configure,
może to prowadzić do nieoczekiwanych rezultatów.
Upewnij się, że podano prawidłową ścieżkę do pliku.
Wykonywanie poleceń S3
Po uzyskaniu prawidłowego pliku konfiguracyjnego można używać z nim poleceń s3cmd. Najpierw należy uzyskać poświadczenia EC2, korzystając z warunku nr 2.
W tym artykule skupimy się tylko na poleceniu ls (wylistowanie dostępnych bucketów).
Istniejący i prawidłowy plik konfiguracyjny - lokalizacja inna niż domyślna
Aby wykonać polecenia S3 przy użyciu innego niż domyślny pliku konfiguracyjnego:
s3cmd -c eodata-config ls
Przykładowe dane wyjściowe:
2017-11-15 10:40 s3://DIAS
2017-11-15 10:40 s3://EODATA
Istniejący i prawidłowy plik konfiguracyjny - domyślna lokalizacja
Jeśli plik konfiguracyjny został zapisany w domyślnej lokalizacji:
s3cmd ls
Parametr -c nie jest wymagany.
Nieistniejący plik konfiguracyjny
Jeśli:
przekazuje nieistniejącą ścieżkę do pliku, oraz
nie używaj konfiguracji,
pojawi się błąd.
Przykład:
s3cmd -c /home/eouser/nonexistentfile ls
Wyjście błędu:
ERROR: /home/eouser/nonexistentfile: None
ERROR: Configuration file not available.
ERROR: Consider using --configure parameter to create one.
Istniejący plik, który nie jest prawidłowym plikiem konfiguracyjnym s3cmd
Jeśli:
przekazać plik, który istnieje, ale
nie jest prawidłowym plikiem konfiguracyjnym s3cmd,
i nie używaj konfiguracji,
mogą wystąpić nieoczekiwane wyniki.
To ostrzeżenie ma również zastosowanie, jeśli domyślny plik konfiguracyjny jest nieprawidłowy.
Ręczne tworzenie minimalnego pliku konfiguracyjnego
Zamiast korzystać z interaktywnego procesu --configure, można ręcznie utworzyć minimalny plik konfiguracyjny s3cmd.
Jest to przydatne, gdy
tworzenia skryptów lub pracy w zautomatyzowanych środowiskach, lub
gdy chcesz szybko skonfigurować dostęp za pomocą edytora.
Wymagana minimalna zawartość
Poniżej znajduje się minimalna zawartość wymagana dla prawidłowego pliku konfiguracyjnego, który łączy się z obiektową pamięcią masową chmury NSIS:
[default]
access_key = <your EC2 access key>
secret_key = <your EC2 secret key>
host_base = s3.waw4-1.cloudferro.com
host_bucket = %(bucket)s.s3.waw4-1.cloudferro.com
signature_v2 = False
use_https = True
Warunek wstępny użytkownika nr 2, aby uzyskać <twój klucz dostępu EC2> i <twój tajny klucz EC2> i użyć ich jako rzeczywistych danych uwierzytelniających.
Tworzenie pliku przy użyciu nano
Aby utworzyć plik konfiguracyjny ręcznie za pomocą edytora tekstowego nano, uruchom:
nano ~/.s3cfg
Wklej zawartość konfiguracji do edytora.
Zapisz i zamknij plik za pomocą:
CTRL+O, aby zapisać plik
ENTER, aby potwierdzić nazwę pliku
CTRL+X, aby wyjść z edytora
Aby chronić plik, ustaw bezpieczne uprawnienia:
chmod 600 ~/.s3cfg
Korzystanie z niestandardowej ścieżki konfiguracji
Plik konfiguracyjny można również zapisać w niestandardowej lokalizacji:
nano ~/my-s3cfg-file
Po zapisaniu można go używać z opcją -c:
s3cmd -c ~/my-s3cfg-file ls
Nagłówek sekcji [default] jest wymagany. s3cmd nie rozpozna pliku jako poprawnego bez niego, a polecenia mogą zakończyć się niepowodzeniem po cichu lub z tajemniczymi błędami.
Utrzymywanie oddzielnych plików konfiguracyjnych s3cmd
Podczas programowania w Pythonie i s3cmd, najlepszą praktyką jest utrzymywanie oddzielnych plików konfiguracyjnych i posiadanie oddzielnych
produkcja,
testowanie i
środowiska rozwojowe.
Jako przykład skoncentrujmy się tylko na środowiskach produkcyjnych i testowych.
Korzyści z oddzielenia plików konfiguracyjnych s3cmd są następujące
uniknąć przypadkowego przesłania lub usunięcia danych w środowisku produkcyjnym podczas testowania;
Każde środowisko może używać innego zestawu poświadczeń, punktów końcowych lub uprawnień;
użytkownik zachowuje przejrzystość i kontrolę nad tym, które połączenie jest aktywne.
Przykładowa konfiguracja dla środowisk produkcyjnych i testowych
Utwórz dwa oddzielne pliki w swoim katalogu domowym:
nano ~/s3cfg-prod
nano ~/s3cfg-test
Każdy plik powinien zawierać wymaganą konfigurację z prawidłowymi poświadczeniami dla danego środowiska.
Następnie można uruchomić s3cmd z odpowiednim plikiem przy użyciu flagi -c:
# For production
s3cmd -c ~/s3cfg-prod ls
# For testing
s3cmd -c ~/s3cfg-test ls
Aby zapobiec przypadkowej edycji lub ujawnieniu, należy ograniczyć uprawnienia do każdego pliku:
chmod 600 ~/s3cfg-prod ~/s3cfg-test
Wskazówka
Używaj znaczących nazw, takich jak s3cfg-prod i s3cfg-test, aby wyraźnie rozróżniać środowiska w skryptach i poleceniach.
Co można zrobić dalej?
Możesz użyć s3cmd do kilku typowych zadań: