Open ericxtang opened 5 years ago
I'm looking into this ticket now @ericxtang ... does this kind of logging suffice? This is an older ticket, so logging might have changed.
As for how to validate credentials on boot-up, it seems like we'd have to call a service that throws invalid access key id exceptions, such as the file upload function in s3.go
. We could verify that the s3creds
provided match a regular expression that describes aws credentials at startup and rule out improperly formatted creds.
Make sure the stream playable
ffplay http://localhost:8935/stream/current.m3u8
or ffplay http://localhost:8935/stream/844e658a/source.m3u8
?
I think trying to upload & delete a small file on boot-up in this case will create a better user experience.
Potentially, provide credentials can only have rights to write and no rights to delete.
Good point. I think in that case, writing a simple test file would be helpful - even if it leave some artifact there.
Cool, by simple test file
do you mean, we just try to do an upload on boot-up, even if delete is not an option? Presumably with a tiny file?
Cool, by
simple test file
do you mean, we just try to do an upload on boot-up, even if delete is not an option? Presumably with a tiny file?
Yes. I think if upload fails, we should exit. And then we can try to delete the file (it's fine if that fails).
Describe the bug The node should show an error if it's started with the wrong S3 auth info.
To Reproduce
Expected behavior If wrong S3 auth is provided, we should either: