LSR's picture

Hello,

 

Newly installed turnkey appliance running in my building. No issues with giving the hub API key to the webmin interface. 

TKLBAM errors on upload to amazon and gives up after 5 tries:

Uploading s3://s3-eu-west-1.amazonaws.com/tklbam-yibysi4jdq3dnnxh/duplicity-full.20130910T151200Z.vol1.difftar.gpg to STANDARD Storage
Upload 's3://s3-eu-west-1.amazonaws.com/tklbam-yibysi4jdq3dnnxh/duplicity-full.20130910T151200Z.vol1.difftar.gpg' failed (attempt #1, reason: S3ResponseError: S3ResponseError: 417 Expectation failed 

Any ideas how to fix? Or is this an issue with EU WEST (ireland) ?

Cheers

Forum: 
Jeremy Davis's picture

Do you have a firewall between your appliance and the net? That would be the most obvious possibility...

Alexander's picture

I have the same issue with turnkey-redmine-12.1-squeeze-amd64.
For the test purpose I have install

turnkey-redmine-12.1-squeeze-i386
and
turnkey-core-12.1-squeeze-amd64

tklbam-backup produce the same S3ResponseError: 417

With new-installed

turnkey-redmine-11.1-lucid-x86

tklbam-backup/restore work fine without any problem.
ESXi 5.0.0 free hipervisor have been used in all cases with the same network environment
on the same Hub account. AWS region Tokyo (North-East Asia)

Related links:

http://www.turnkeylinux.org/forum/support/20130130/tklbam-backup...

https://github.com/turnkeylinux/tracker/issues/94

Any ideas how to fix it?

 


Jeremy Davis's picture

I just downloaded turnkey-core-12.1-squeeze-amd64.iso, installed to a fresh VM (KVM), applied by TKLBAM API key and ran a backup. It completed successfully...

--------------[ Backup Statistics ]--------------
StartTime 1379031322.00 (Fri Sep 13 00:15:22 2013)
EndTime 1379031322.08 (Fri Sep 13 00:15:22 2013)
ElapsedTime 0.08 (0.08 seconds)
SourceFiles 79
SourceFileSize 864021 (844 KB)
NewFiles 79
NewFileSize 864021 (844 KB)
DeletedFiles 0
ChangedFiles 0
ChangedFileSize 0 (0 bytes)
ChangedDeltaSize 0 (0 bytes)
DeltaEntries 79
RawDeltaSize 753429 (736 KB)
TotalDestinationSizeChange 664921 (649 KB)
Errors 0
-------------------------------------------------

So I can only assume that it is a network issue of some type - it's the only thing that makes sense... Considering that your v11.1 appliance works ok then perhaps there is some difference in the way the networking is configured between these machines (in the VMware settings). Or perhaps there is some incompatability between the networking on Debian (basis of v12.x and later) vs Ubuntu (basis of v11.x and previous) in regards to VMware. Whilst technically VMware should support it, the reality seems to be that it is not always...

To help you try and work it out, can you ping AWS servers from within the v12.x VM?

Alexander's picture

In my case ping of s3-ap-northeast-1.amazonaws.com address is ok for all

turnkey-redmine-12.1-squeeze-amd64
and
turnkey-redmine-12.1-squeeze-i386
and
turnkey-core-12.1-squeeze-amd64
and
turnkey-redmine-11.1-lucid-x86

root@v-redmine64 /# ping s3-ap-northeast-1.amazonaws.com
PING s3-ap-northeast-1.amazonaws.com (103.246.150.128) 56(84) bytes of data.
64 bytes from 103.246.150.128: icmp_req=1 ttl=236 time=299 ms
64 bytes from 103.246.150.128: icmp_req=2 ttl=236 time=299 ms

tklbam-backup work good only with turnkey-redmine-11.1-lucid-x86


Jeremy Davis's picture

@LSR - I just tried to ping s3-eu-west-1.amazonaws.com too and it times out for me too...  I have no idea why it's not working but perhaps it's an issue on Amazon's end? Surely it wouldn't be out this long though...?

@Alexander - I can ping s3-ap-northeast-1.amazonaws.com too. I was thinking that it may have been some sort of networking issue with Debian vs Ubuntu on VMware... But perhaps not if you can ping ok from within the server but TKLBAM fails...

I'm going to add a note to the issue you link to Alexander and encourage the devs to have a look at this... 

In the meantime all I can suggest is perhaps try reinitialsiing TKLBAM... Not sure if that will make any difference but perhaps worth a try...

Jeremy Davis's picture

No in the sense that there is no switch or option that I am aware of to force it to use a specific location.

But the code is all on GitHub so if you're handy with Python (or know someone who is) I'm sure you could hack it to do that...

Another thought is that you could try uninstalling and reinstalling TKLBAM (in the hope that it will realise that there is no response from that domain name...)

apt-get remove --purge tklbam
apt-get update
apt-get install tklbam
tklbam-init --force <HUB_KEY>

Although it may make no difference...

Another idea (which may not have a lot of merrit) is adjust the hosts file on your server (temporarily) to point to the desired IP. If you do that make sure that you run a full backup straight away...

Jeremy Davis's picture

TKLBAM v1.3 was recently released so perhaps try updating it...

apt-get update
apt-get install tklbam

Please post back with what (if any) difference that makes.

Jeremy Davis's picture

The update? Did it report that TKLBAM is already at the latest version? Or the TKLBAM backup (still)?

Either way...bugger!

Jeremy Davis's picture

It looks like the TKLBAM v1.3 package hasn't made it to TKLv12.x (Squeeze) repo yet... TBH I can't be sure but I suspect that it will work...

If you wish to test it then I suggest that you try downloading the relevant package (from here) keep in mind that i386 refers to 32 bit and amd64 refers to 64 bit (if you get the wrong one no doubt your system will let you know when you try to install (will error)

Install with

dpkg -i <package-name>.deb

If it doesn't work, please post the error and we'll see what we can do...

Jeremy Davis's picture

Assuming you are using 32 bit version (if using 64 bit substitiute "amd64' whenever it says 'i386'...)

wget http://archive.turnkeylinux.org/debian/pool/wheezy/main/p/pycurl-wrapper/pycurl-wrapper_1.1%2b3%2bg6509b67_i386.deb
dpkg -i pycurl-wrapper_1.1+3+g6509b67_i386.deb

And then to fix the half installed new version of TKLBAM:

apt-get install -f

And now the new version of TKLBAM is installed.... Now I just hope that it resolves the issue you've been having....

[after thought] There are also new version of tklbam-squid and tklbam-squid-common... Perhaps they might be worth updating too? I'd probably test TKLBAM after installing the new version, then if that still isn't working try installing both of those tklbam-squid packages and test again... If it still doesn't work then we'll just have to throw our arms in the air and swear or something...

Jeremy Davis's picture

After closer inspection it seems that Python v2.7 is the default in 13.x (Wheezy ) whereas in v12.x (Squeeze) the default is v2.6... That is why you are getting that error.... (because the newer version of pycurl_wrapper is installed to the python2.7 directory).

You can work around this error by creating a symlink to the new pycurl_wrapper like this:

ln -s /usr/lib/python2.7/dist-packages/pycurl_wrapper.py /usr/lib/python2.6/dist-packages/pycurl_wrapper.py

But TBH I'm not sure what other issues we might be creating.... But seeing as TKLBAM wasn't working before I guess we don't have anything to lose...

Jeremy Davis's picture

TBH I have no idea why you (and a couple of others) are having these issues. It doesn't make any sense to me as most users are not having any problems... There must be something unique about the circumstance. It's especially interesting that a previous TKLBAM version owrks ok (I assume under the same circumstance).

Have you tried the new TKL v13.0 appliances? AFAIK they have the new version of TKLBAM preinstalled...

Alexander's picture

1. TKLBAM from 12.1 & 13.0 versions of the Turnkey Linux produce Error: 417 Expectation failed while backup to AWS, but 11.1 work without the error.

2. Adding option

ignore_expect_100 on

in /etc/squid/squid.conf of my proxy resolve the problem for me.

3. May be the issue is the result of RFC 2616 violation:

http://www.squid-cache.org/Doc/config/ignore_expect_100/

http://www.ietf.org/rfc/rfc2616.txt


Add new comment