svfs uses public storage-url even when you've specified private one
kayrus opened this issue · 4 comments
Context
- svfs version : 0.9.1
- storage provider : Rackspace Swift
- product : Openstack Mitaka
Steps to reproduce this issue :
- mount storage using these settings:
svfs mount --device swift --mountpoint /home/user/SWIFT --default-uid=500 --default-gid=500 --os-auth-url=http://%PRIVATE_IP%:5000/v2.0 --os-username=%USER% --os-password=%PASSWORD% --os-tenant-name=swift --os-container-name=container --os-storage-url=http://%private_ip%:8080/v1/AUTH_%ID% --debug - Run it for couple of hours with high load.
- Suddenly it switches to https protocol and public IP:
time="2017-07-19T19:36:15Z" level=debug msg="-> [ID=0x4edefd] Read 131072" source=fuse
time="2017-07-19T19:36:15Z" level=debug msg="-> [ID=0x4edef4] Open error=EIO: Get https://%PUBLIC_IP%:8080/v1/AUTH_%ID%/container/file1: x509: cannot validate certificate for %PUBLIC_IP% because it doesn't contain any IP SANs" source=fuse
time="2017-07-19T19:36:15Z" level=debug msg="-> [ID=0x4edefc] Open error=EIO: Get https://%PUBLIC_IP%:8080/v1/AUTH_%ID%/container/file2: x509: cannot validate certificate for %PUBLIC_IP% because it doesn't contain any IP SANs" source=fuse
time="2017-07-19T19:36:15Z" level=debug msg="<- Read [ID=0x4edefe Node=0x46bd Uid=505 Gid=506 Pid=20316] 0x2c 110592 @0x5c000 dir=false fl=0 lock=0 ffl=OpenReadOnly" source=fuse
Results you expected :
svfs should always use provided private os-storage-url parameter
Results you observed :
svfs suddenly switches to public os-storage-url
P.S. I didn't find logs which tell why svfs switched to public https. I just have info that previous operation was successful, then next operation failed because of the certificate validation.
Ok, looks like this relates to github.com/xlucas/swift's this string.
Looks like this issue is already fixed in upstream ncw swift repo. Why do you use fork as a dependency?
Some extra features are implemented in the fork to avoid cluttering the project with helpers function (like manifest copy, support for additional object headers, rate limiting etc). However as I'm refactoring a good part of the project, we may free that dependency in a near future and upstream most of the changes.
Basically initial issue is still not resolved. We should not overwrite StorageUrl variable on re-auth. There is no possibility to open an issue in https://github.com/xlucas/swift project. Could you reopen this issue and fix the underlying dependency?