Wprawdzie planowałem dziś napisać m.in. o S3, ale skrót S3 nie miał oznaczać “pamięci internetowej” (Storage Obiektowy), o której pisałem ostatnio (Simple Storage Service (S3) w systemie Linux).

Jednak podczas porannego sprawdzania “raportów” m.in. z serwerów trafiłem na błąd dotyczący (nie)dostępności na jednym z serwerów (konkretnie chodzi o Raspberry Pi, czyli też swego rodzaju serwer, w dodatku fizyczny ;-)) zasobu korzystającego właśnie z pamięci S3 – rozwiązanie okazało się banalne, to jednak być może przyda się również komuś z Was…

Simple Storage Service (S3): RequestTimeTooSkewed

Było to o tyle dziwne, że od ostatniego pomyślnego podłączenia pamięci w systemie nie były przeprowadzane żadne zmiany – nie było nawet restartu czy aktualizacji).

Wprawdzie na co dzień zasób montowany jest przez skrypt, to na potrzeby analizy postanowiłem całą operację (montowanie zasobu, podstawowe operacje s3fs) wykonać ręcznie.

Na początek montowanie zasobu:

sudo s3fs kontener /lokalny/punkt/montowania -o url="https://e24files.com" -o passwd_file=/ścieżka/do/pliku/autoryzacyjnego -o allow_other

Niby wszystko OK, brak błędów… Sprawdzam więc zamontowane w systemie zasoby/dyski:

df -h

I w pierwszej linijce widzę coś takiego:

/lokalny/punkt/montowania - transport endpoint is not connected

Powyższe napisałem z pamięci, więc może się trochę różnic od tego co Wy ew. zobaczycie ;-)

Z tego widać, że coś jest nie tak już na etapie podłączania pamięci S3 do lokalnego systemu plików, tak więc do polecenia dodałem 2 parametry, które powinny włączyć coś na kształt tryby debugowania:

-f -d

Całe polecenie wyglądało tak:

sudo s3fs kontener /lokalny/punkt/montowania -o url="https://e24files.com" -o passwd_file=/ścieżka/do/pliku/autoryzacyjnego -o allow_other -f -d

I można powiedzieć (napisać), że w nieszczęściu miałem szczęście, bo podczas tej próby otrzymałem takie informacje:

[CRT] s3fs.cpp:set_s3fs_log_level(250): change debug level from [CRT] to [INF]
[INF]     s3fs.cpp:set_moutpoint_attribute(4091): PROC(uid=0, gid=0) - MountPoint(uid=0, gid=0, mode=40755)
[CRT] s3fs.cpp:s3fs_init(3297): init v1.79(commit:xxxxxxx) with OpenSSL
[INF] s3fs.cpp:s3fs_check_service(3653): check services.
[INF]       curl.cpp:CheckBucket(2647): check a bucket.
[INF]       curl.cpp:prepare_url(4140): URL is https://e24files.com/kontener/
[INF]       curl.cpp:prepare_url(4172): URL changed is https://kontener.e24files.com/
[INF]       curl.cpp:insertV4Headers(2069): computing signature [GET] [/] [] []
[INF]       curl.cpp:url_to_host(99): url is https://e24files.com
[INF]       curl.cpp:RequestPerform(1755): HTTP response code 400 was returned, returing EIO.
[ERR] curl.cpp:CheckBucket(2685): Check bucket failed, S3 response: <?xml version="1.0" encoding="UTF-8"?><Error><Code>InvalidArgument</Code></Error>
[WAN] s3fs.cpp:s3fs_check_service(3694): Could not connect, so retry to connect by signature version 2.
[INF]       curl.cpp:CheckBucket(2647): check a bucket.
[INF]       curl.cpp:prepare_url(4140): URL is https://e24files.com/kontener/
[INF]       curl.cpp:prepare_url(4172): URL changed is https://kontener.e24files.com/
[INF]       curl.cpp:RequestPerform(1760): HTTP response code 403 was returned, returning EPERM
[ERR] curl.cpp:CheckBucket(2685): Check bucket failed, S3 response: <?xml version="1.0" encoding="UTF-8"?><Error><Code>RequestTimeTooSkewed</Code></Error>
[CRT] s3fs.cpp:s3fs_check_service(3710): invalid credentials - result of checking service.

Wprawdzie jest tego trochę, ale mam taki zwyczaj, że błędy zaczynam sprawdzać od końca (najczęściej się sprawdza), a w tym wypadku będzie to ten fragment:

[ERR] curl.cpp:CheckBucket(2685): Check bucket failed, S3 response: <?xml version="1.0" encoding="UTF-8"?><Error><Code>RequestTimeTooSkewed</Code></Error>

A konkretnie:

Check bucket failed, S3 response: RequestTimeTooSkewed

Co oznacza, że prawdopodobniej na naszym komputerze mamy (znacznie) inny czas niż na serwerze S3, i trzeba to skorygować.

Czas sprawdzicie za pomocą polecenia:

date

I faktycznie w tym przypadku tu był problem – Raspberry Pi nie posiada (w standardzie, ale da się dodać) sprzętowego zegara (RTC) więc czas jest ustalany za pomocą usługi NTP (np. przez internet) lub za pomocą aplikacji fake-hwclock, która sprawdza się przy restartach, to przy dłuższych “przestojach” (np. brak zasilania) już nie bardzo.

O moich bojach z usługą NTP w systemie Raspbian (Debian) na potrzeby m.in. usługi S3 przeczytacie więcej na tej stronie…