| 1 | | Am I considered to be spam? |
| | 1 | Relevant to this issue, is my experience provisioning new S4 subscriptions. |
| | 2 | The provisioning process began failing unexpectedly on Tuesday March 03, 2014. |
| | 3 | |
| | 4 | I don't immediately recall when I last ran it prior to that, but it was probably within a week (i.e. since Februrary 24th). |
| | 5 | |
| | 6 | I ssh'd in to the SSEC2 which had been launched during the failed provisioning. |
| | 7 | I manually repeated the provisioning steps until I reached the first step that failed. |
| | 8 | |
| | 9 | The failing step was: {{{sudo python ./setup.py install}}} run in the context of {{{txAWS-0.2.1.post4}}} 's 'base' directory. |
| | 10 | |
| | 11 | I upgraded the version of txAWS used during deployment to {{{post5}}} , by applying a commit daira wrote a while back. {{{post5}}} depends on {{{python-dateutil}}} instead of {{{Epsilon}}}. |
| | 12 | |
| | 13 | Here's the relevant commit: {{{https://github.com/LeastAuthority/leastauthority.com/commit/05ce3d44708c89158c6ae828d2a11827b74001f7}}} |
| | 14 | |
| | 15 | After making _only_ that change, the S4 provisioning process began functioning as expected again. (As evidenced by a "smoke-test" on an S4 instance provisioned as above.) |
| | 16 | |
| | 17 | The following is the version info from the provisioned S4: |
| | 18 | |
| | 19 | {{{ |
| | 20 | customer@ip-10-185-216-61:~$ /home/customer/LAFS_source/bin/tahoe --version |
| | 21 | allmydata-tahoe: 1.9.1.dev1, |
| | 22 | foolscap: 0.6.3, |
| | 23 | pycryptopp: 0.6.0.1206569328141510525648634803928199668821045408958, |
| | 24 | zfec: 1.4.24, |
| | 25 | Twisted: 12.2.0, |
| | 26 | Nevow: 0.10.0, |
| | 27 | zope.interface: unknown, |
| | 28 | python: 2.7.3, |
| | 29 | platform: Linux-Ubuntu_12.04-i686-32bit_ELF, |
| | 30 | pyOpenSSL: 0.12, |
| | 31 | simplejson: 2.3.2, |
| | 32 | pycrypto: 2.4.1, |
| | 33 | pyasn1: 0.1.7, |
| | 34 | mock: 1.0.1, |
| | 35 | sqlite3: 2.6.0 [sqlite 3.7.9], |
| | 36 | setuptools: 0.6c16dev3 |
| | 37 | |
| | 38 | customer@ip-10-185-216-61:~$ |
| | 39 | }}} |
| | 40 | |
| | 41 | And the version of txAWS: |
| | 42 | |
| | 43 | {{{ |
| | 44 | customer@ip-10-185-216-61:~$ python -c 'import txaws;print txaws' |
| | 45 | <module 'txaws' from '/usr/local/lib/python2.7/dist-packages/txAWS-0.2.1.post5-py2.7.egg/txaws/__init__.pyc'> |
| | 46 | customer@ip-10-185-216-61:~$ |
| | 47 | }}} |
| | 48 | |
| | 49 | As you can see from the tahoe version information, the _current_ version deployed with S4, does _not_ depend on cryptography because the version of pyOpenSSL it uses is: {{{0.12}}}. |
| | 50 | When we upgrade to newer versions of Tahoe-LAFS (an urgent needed upgrade, to fulfill customer-driven feature requests) however, this issue will effect S4. |
| | 51 | |
| | 52 | Finally the upgrade to txAWS-0.2.1.post5 is _not_ in production, and we can therefore expect new signups to fail. |
