Hi, the German speaking Zope Users Group (DZUG e.V.) organizes a series of 4 sprints this year to support feature development within the proximity of the ZTK and solve problems encountered by Zope, Plone and Python developers. This is the announcement of the first sprint, although it's a bit late, I'd like you to consider whether you might wanna join us. Where and when ============== The sprint is scheduled for April 6th 2011 to April 8th 2011 and will take place at the Hasso-Plattner-Institut in Potsdam, Germany, which is where Martin v. Löwis is working at. On April 8th there will be a separate event in the evening for presenting the results of the sprint to Non-Sprinters in a relaxed atmosphere. Topics ====== The sprint topics will revolve around PyPI and zc.buildout including: * Making PyPI faster (Chameleon integration) * Adding support for the PyPI mirroring protocol to zc.buildout * Discussing how to deal with "private" releases * Porting zc.buildout to Python 3 More topic suggestions in this area are welcome - we'll gather them and review based on the following criteria: * Each topic in the sprint should be supported and worked on by at least two developers from independent organisations (to ensure a reasonable amount of varying perspective). * Each topic should be specific enough and limited in scope so that we can deal with it in 2 days in such a way that we get a result we can continue to build on and use. * We do not only want to see code but also documentation: be prepared to write module-specific developer documentation as well as documentation on how to use what you build. * Each topic shall be presented to others on Friday evening in a way that clarifies it's relevance and context. Please send your topic suggestions to sprints@dzug.org. Participation ============= Developers may participate after asking for an invitation and committing to one of the selected topics or suggesting a topic that gets selected. The organisation team may actively invite developers whose reputation suggests that they would be highly valuable within the scope of the sprint. Please be aware that the main working language of the sprint will be German. We're happy to have non-German-speaking developers around but be prepared to hear quite some amount of our tongue. ;) Please send your requests for participation by email to sprints@dzug.org Sponsoring ========== Organizing those sprints requires financial support - to make this sprint series sustainable we kindly ask you to consider sponsoring our effort. We have prepared sponsoring packages of 250 EUR to support a single sprint or 800 EUR to support all 4 sprints. If you're interested in a sponsoring package, please contact me by direct email. More information ================ More information is available on the sprint website in German at http://www.zope.de/community/veranstaltungen/1.-dzug-sprint-2011 If you would like to get more information in English, feel free to respond to this post or contact me personally. Best regards, Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting, development, hosting, operations
Hi Christian, On 25/03/2011 16:49, Christian Theune wrote:
the German speaking Zope Users Group (DZUG e.V.) organizes a series of 4 sprints this year to support feature development within the proximity of the ZTK and solve problems encountered by Zope, Plone and Python developers.
<snip>
Topics ======
* Discussing how to deal with "private" releases
FWIW, I've had no problems with this, here's a sample buildout.cfg: [buildout] extensions = lovely.buildouthttp find-links = https://example.com/password/protected/folder ...and just dump the .tgz sdists in that folder. Of course, if you don't need password protection such as when you have your "egg server" on a private network, you just need the find-links. I'm not really sure why people have written a complicated array of "egg servers" and the like when a simple http or file system served folder is just fine ;-) cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
Hello, On Fri, 25 Mar 2011 19:24:05 +0000 you wrote:
Hi Christian,
On 25/03/2011 16:49, Christian Theune wrote:
the German speaking Zope Users Group (DZUG e.V.) organizes a series of 4 sprints this year to support feature development within the proximity of the ZTK and solve problems encountered by Zope, Plone and Python developers.
<snip>
Topics ======
* Discussing how to deal with "private" releases
FWIW, I've had no problems with this, here's a sample buildout.cfg:
[buildout] extensions = lovely.buildouthttp find-links = https://example.com/password/protected/folder
...and just dump the .tgz sdists in that folder.
Of course, if you don't need password protection such as when you have your "egg server" on a private network, you just need the find-links.
I'm not really sure why people have written a complicated array of "egg servers" and the like when a simple http or file system served folder is just fine ;-)
Well the problem is that it's not always so simple. For me a release process is preferably a single command or a single click on a button. -- Best regards, Adam GROSZER -- Quote of the day: To look up and not down, To look forward and not back, To look out and not in, and To lend a hand. - Edward Everett Hale
On Tue, Mar 29, 2011 at 14:16, Adam GROSZER <agroszer.ll@gmail.com> wrote:
Well the problem is that it's not always so simple. For me a release process is preferably a single command or a single click on a button.
Both zest.releaser and jarn.mkrelease offer you simple single-command release options. I use jarn.mkrelease to make releases to private, password protected folders on our dist.jarn.com 'egg server' (apache directory indexes). -- Martijn Pieters
* Martijn Pieters <mj@zopatista.com> [2011-03-29 20:59]:
On Tue, Mar 29, 2011 at 14:16, Adam GROSZER <agroszer.ll@gmail.com> wrote:
...and just dump the .tgz sdists in that folder. Well the problem is that it's not always so simple. For me a release process is preferably a single command or a single click on a button.
Both zest.releaser and jarn.mkrelease offer you simple single-command release options. I use jarn.mkrelease to make releases to private, password protected folders on our dist.jarn.com 'egg server' (apache directory indexes).
(Shameless plug: ;-) gocept.zestreleaser.customupload is a plugin for zest.releaser that allows uploading the created egg via scp. We use this to put our non-public eggs into a folder that's served (and htpasswd protected) by an Apache or somesuch, no complicated "egg server" business required. Wolfgang
On 03/30/2011 07:12 AM, Wolfgang Schnerring wrote:
* Martijn Pieters<mj@zopatista.com> [2011-03-29 20:59]:
On Tue, Mar 29, 2011 at 14:16, Adam GROSZER<agroszer.ll@gmail.com> wrote:
...and just dump the .tgz sdists in that folder. Well the problem is that it's not always so simple. For me a release process is preferably a single command or a single click on a button.
Both zest.releaser and jarn.mkrelease offer you simple single-command release options. I use jarn.mkrelease to make releases to private, password protected folders on our dist.jarn.com 'egg server' (apache directory indexes).
(Shameless plug: ;-) gocept.zestreleaser.customupload is a plugin for zest.releaser that allows uploading the created egg via scp. We use this to put our non-public eggs into a folder that's served (and htpasswd protected) by an Apache or somesuch, no complicated "egg server" business required.
So those solutions then require you to put the password for accessing it somewhere during deployment ... where is that for you? -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting, development, hosting, operations
* Christian Theune <ct@gocept.com> [2011-03-30 13:18]:
On 03/30/2011 07:12 AM, Wolfgang Schnerring wrote:
* Martijn Pieters<mj@zopatista.com> [2011-03-29 20:59]:
On Tue, Mar 29, 2011 at 14:16, Adam GROSZER<agroszer.ll@gmail.com> wrote:
...and just dump the .tgz sdists in that folder. Well the problem is that it's not always so simple. For me a release process is preferably a single command or a single click on a button.
Both zest.releaser and jarn.mkrelease offer you simple single-command release options. I use jarn.mkrelease to make releases to private, password protected folders on our dist.jarn.com 'egg server' (apache directory indexes).
(Shameless plug: ;-) gocept.zestreleaser.customupload is a plugin for zest.releaser that allows uploading the created egg via scp. We use this to put our non-public eggs into a folder that's served (and htpasswd protected) by an Apache or somesuch, no complicated "egg server" business required.
So those solutions then require you to put the password for accessing it somewhere during deployment ... where is that for you?
We put the password into the buildout.cfg. Wolfgang
On 30/03/2011 12:29, Wolfgang Schnerring wrote:
(Shameless plug: ;-) gocept.zestreleaser.customupload is a plugin for zest.releaser that allows uploading the created egg via scp. We use this to put our non-public eggs into a folder that's served (and htpasswd protected) by an Apache or somesuch, no complicated "egg server" business required.
So those solutions then require you to put the password for accessing it somewhere during deployment ... where is that for you?
We put the password into the buildout.cfg.
lovely.buildouthttp keeps the passwords in a seperate file in yoru .buildout directory... cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
On Fri, Mar 25, 2011 at 3:24 PM, Chris Withers <chris@simplistix.co.uk> wrote:
Hi Christian,
On 25/03/2011 16:49, Christian Theune wrote:
the German speaking Zope Users Group (DZUG e.V.) organizes a series of 4 sprints this year to support feature development within the proximity of the ZTK and solve problems encountered by Zope, Plone and Python developers.
<snip>
Topics ======
* Discussing how to deal with "private" releases
FWIW, I've had no problems with this, here's a sample buildout.cfg:
... We do something similar with sftp (zc.buildoutsftp). To publish eggs, we just use scp. The advantage of this is that it leverages ssh infrastructure, so *no* additional password management is needed. This is wildly better, IMO, than keeping passwords in clear text in your buildout configuration or in a dot file. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton
On Wed, Mar 30, 2011 at 15:08, Jim Fulton <jim@zope.com> wrote:
We do something similar with sftp (zc.buildoutsftp). To publish eggs, we just use scp. The advantage of this is that it leverages ssh infrastructure, so *no* additional password management is needed. This is wildly better, IMO, than keeping passwords in clear text in your buildout configuration or in a dot file.
That depends on your deployment scenarios. We generate separate passwords per customer, and give them a dedicated URL to load their private eggs from, then put the password in the buildout.cfg. To load the buildout.cfg in the first place, the exact same password is used. Managing SSH accounts and keys for those customers would cost us much more overhead, and would complicate our instructions for deployment to them. On the other hand, for deployments of a buildout from a SVN repository already served over SSH would make the sftp route the logical choice. -- Martijn Pieters
On Thu, Mar 31, 2011 at 5:38 AM, Martijn Pieters <mj@zopatista.com> wrote:
On Wed, Mar 30, 2011 at 15:08, Jim Fulton <jim@zope.com> wrote:
We do something similar with sftp (zc.buildoutsftp). To publish eggs, we just use scp. The advantage of this is that it leverages ssh infrastructure, so *no* additional password management is needed. This is wildly better, IMO, than keeping passwords in clear text in your buildout configuration or in a dot file.
That depends on your deployment scenarios. We generate separate passwords per customer, and give them a dedicated URL to load their private eggs from, then put the password in the buildout.cfg. To load the buildout.cfg in the first place, the exact same password is used.
Managing SSH accounts and keys for those customers would cost us much more overhead, and would complicate our instructions for deployment to them.
On the other hand, for deployments of a buildout from a SVN repository already served over SSH would make the sftp route the logical choice.
Some customers are too dumb to be secure. OK, makes sense. :) Seriously, I assume this is a read-only scenario, in which case having clear-text passwords laying around in prominent places seems less problematic. If they could write to the repo, then I would still have serious problems with this approach. Another approach would be to integrate with some secure key-management service (keychain) on the customer's machines, but I expect that would be as painful as helping them figure out ssh. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton
participants (6)
-
Adam GROSZER -
Chris Withers -
Christian Theune -
Jim Fulton -
Martijn Pieters -
Wolfgang Schnerring