See my responses inline.
On Thu, Aug 16, 2012 at 10:52 AM, Kevin Fenzi <email@example.com> wrote:
> On Wed, 15 Aug 2012 17:42:27 -0600
> Clint Savage <firstname.lastname@example.org> wrote:
>> For those of you who may be interested, we're finally moving forward
>> to update the fedora pastebin server. We're planning the new pastebin
>> to represent fpaste.org and be an instance of sticky-notes
>> Athmane already has a puppet configuration and this is noted in the
>> ticket below.
> A few questions:
> Is there any ongoing maint we need to do with sticky-notes?
Probably any php security issues should be watched. We do use a mysql
database for this application, so probably good to keep that backed up
from time to time. The only other maintenance is updates to
sticky-notes. I suspect we'll probably want to purge the pastes at
some point in time, so there might be a need for a cron job to do such
> Do we need to populate a badwords blacklist ?
Yes, there is a place to do that in the admin.
> Are there any SOP's that need written? I know it has an admin
> interface, we should note what that might be useful for and how to
> access it for admins. It would be good to describe how to remove a
> paste that had copyrighted stuff or something.
We should probably investigate and document the best configs for the
Project Honey Pot configuration. I also understand that Fedora Project
will need an account at http://www.projecthoneypot.org/httpbl_api.php
to use the honey pot.
> No google+ share link?
I know, right!?
> What final url do we want to use?
> https://something else?
I'm a big fan of https://paste.fedoraproject.org but
http://fedoraproject.org/paste is fine as well.
> Do we want to cache pastes with varnish? Or not bother?
What value would this gain us? I suppose if a ton of people were
visiting a specific paste right after it was posted, we could see a
>> We will also be needing to work with the maintainer of fpaste to
>> update the configuration there and should have that part done soon as
> I think this would be good to have in place... just for now an option
> or a config file that points it to the staging instance. Once we go
> live we can push out a updated fpaste again that changes the default.
I took a look last night at fpaste and was able to hack it to work
with the development version of sticky-notes. From what I can tell the
old fpaste.org did things differently in terms of return details and
such. I'm planning on submitting the patches upstream today.
The fpaste client is written to work specifically with fpaste.org and
not much else. This is not necessarily a bad thing. I just don't know
if it would be better to just create fedpaste and have it provide
fpaste or something like that going forward. I think I want to ask the
maintainer of fpaste how they would like to proceed and see where we
go from there.
infrastructure mailing list