mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)
[staff profile] mark
Historically we've had a policy of trying to actively support people who might be running the DW code somewhere and that has influenced how we've built things, such as making many things options in the codebase and also maintaining support for legacy configurations and systems that we might not use in Dreamwidth.org's production environment.

Since there's not (and never much has been) people seriously running DW code for any major service, I would rather for us to focus our limited development resources on our own development needs. To be totally clear, we will continue to maintain Dreamwidth the open source platform and people are very welcome to use it. You just might have to either do some of your own development or use a production environment that closely mirrors ours.

Some examples of what this update means:

* Perlbal is no longer used at DW HQ and we're removing all support for it
* MogileFS is on its way out (to be replaced by either simple on-disk storage or Amazon S3)
* Master-Master support is deprecated and will be removed
* Configuration options are being cleaned up and some things will become non-optional (i.e. compression, etc)
* No more support for 32 bit systems (think this is gone already tho)

My goal here is to make Dreamwidth development faster and easier for actually developing on Dreamwidth.org. We'll still have to make it possible (and easier!) for people to run DW (if nothing else for our own developers!) but the number of at-scale-production-configurations supported is going down.

As always, comments welcome!
pauamma: Cartooney crab holding drink (Default)
[personal profile] pauamma
It's going down, per http://www.njabl.org/:
March 1, 2013: NJABL is in the process of being shut down. The DNSBL zones have been emptied. After "the Internet" has had some time to remove NJABL from server configs, the NS's will be pointed off into unallocated space (192.0.2.0/24 TEST-NET-1) to hopefully make the shutdown obvious to those who were slower to notice.
(Note: some sitewide spamfilters may use it as part of a default, stock, or example configuration. policyd-weight is one.)
mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)
[staff profile] mark

Hi all,

We're here at OSCON (O'Reilly's Open Source Conference in Portland) with a bunch of the volunteers who work on Dreamwidth. Related to this, we've finally decided to force an upgrade to our Perl base version required.

[personal profile] kareila says it well:

Hello all! A few facts have recently come to our attention:

1) Perl 5.10 has a significant number of new, desirable features over Perl 5.8.

2) Perl 5.10 was released 5 years ago, so it's reasonable to assume most people are using Perl 5.10 or newer in production.

3) We are, in fact, using Perl 5.10 in production.

Therefore, we are planning to start requiring Perl 5.10 as we fix bugs and add new features in the future. If you are running a Dreamwidth installation on a version of Perl older than 5.10, now would be an excellent time to consider upgrading.

We are also considering moving to 5.12 or 5.14 soon. We need to do some more investigation and also validate the system on those versions. But for now, consider 5.10 as required.

Thanks!

pauamma: Cartooney crab holding drink (Default)
[personal profile] pauamma
$TRUST_X_HEADERS is a configuration variable you should set to true (1) if you're using proxy you control and trust (eg, perlbal), so you can retrieve the real (external) source IP address of incoming requests, instead of seeing them as coming from 127.0.0.1 or the IP address your proxy/load balancer/whatever runs on. By default, it's 0, but for dreamhacks and other development hosts, that default isn't practical, so instead of making it default to 0 (with a commented-out line in etc/config.pl to change it to 1), I would make it default to the value of $IS_DEV_SERVER if not defined, with commented-out lines in etc/config.pl to force it to either 0 or 1.

This shouldn't affect production servers, who likely have IS_DEV_SERVER set to 0 and TRUST_X_HEADERS set to 1 already, but it might affect production servers, if any, with unexpected configurations, and the change may surprise developers who didn't set TRUST_X_HEADERS explicitely, so I'm throwing this for discussion here in case I missed some pitfalls, or if there's a way to make it better. I'm also opening a bug linking here, so whatever the outcome of the discussion is, it doesn't fall through the cracks.
pauamma: Cartooney crab holding drink (Default)
[personal profile] pauamma
Apache::LiveJournal::db_logger() was disabled early on as part of the Apache2 conversion. The intent was apparently to revisit that later, but it's been over 3 years and there's no "later" yet. As far as I can tell, Apache::LiveJournal::db_logger() is the only bit that uses LJ::AccessLogRecord, LJ::AccessLogSink, and LJ::AccessLogSink::* (there are other references, but they're in stuff like confcheck, so they don;t count).

Get rid of those? Or is there a planned use or another reason to keep them in the codebase?
pauamma: Cartooney crab holding drink (Default)
[personal profile] pauamma
So Dreamwidth has an incomplete implementation of the LJ::EventLogRecord and LJ::EventLogSink system. Specifically, it's missing LJ::EventLogSink and LJ::EventLogSink::*, and thus doesn't do anything now except waste CPU time and RAM (assuming it's even used anywhere - it's disabled in the stock etc/config*.pl and in the Dreamwidth production configuration). (Note: this has no connection with the ESN system.)

If completed (mostly by importing the missing bits from LiveJournal), it would let us:
- selectively log to the database events listed in http://code.livejournal.org/trac/livejournal/browser/trunk/cgi-bin/LJ/EventLogRecord/
- feed some or all of the same events to an indexer (for full text search of journals) in a way similar to http://code.livejournal.org/trac/livejournal/browser/trunk/cgi-bin/LJ/EventLogSink/SearchIndexer.pm

So it has potential uses if completed, but since Dreamwidth has its own indexer/search engine and no one called for completing it, I think we may as well remove it. Does anyone see any reason for completing it instead? Completing it would mean reverting part of bug 164 - the database logging would still stay out, but the feed-to-indexer bits would return, probably in a modified form).

What do y'all think?
denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)
[staff profile] denise
I realized that we don't have any true list of "production" sites running the DW code, which makes it hard for us to know who to talk to when we get around to starting the DWsite-to-DWsite interoperability features we've been discussing -- not to mention, there are times when there are critical performance, stability, or security patches that should be applied quickly.

I've started a list on the wiki. If you're running a DW code install for an audience -- ie, not a development/hacking machine -- whether that audience is a small group of friends or a larger, more open install, take a second and add your information to the Sites Running the DW Code wiki page.

The format to use:

* Site URL: where your site can be accessed
* Site name: the name people should use when referring to your site
* Best contact method: An email address that will reach the decision-makers for the site (if using a email-to-support category alias, please do not use a public one)
* Open to public: Whether your site has open registration (even with invite code) or is intended for a smaller/targeted audience (aka, a group of friends, or members of another website, etc); also, whether you're ready for registration or still in the process of setting up
* Intended audience: The focus of your site; who it's "for"

Or, for ease of copy/paste:

pauamma: Cartooney crab holding drink (Default)
[personal profile] pauamma
Currently, Dreamwidth supports (somewhat half-heartedly and clumsily) sites with user-visible URLs that look like http://www.example.com:6809/, and I've been wondering about a few things:

1- How many sites running Dreamwidth code actually use that feature? How many couldn't run without it?

2- If you're considering running a Dreamwidth-based site or are working on one, would it or does it need that feature to run?

3- If neither of the above applies to you, do you find that feature important, pleasant, infuriating, or neither? Why?

(Note: I'm not speaking of hosted Dreamhacks here, since even those that use another port internally are mapped to port 80 using Perlbal.)

Profile

dw_dev: The word "develop" using the Swirly D logo.  (Default)
Dreamwidth Open Source Development

October 2017

S M T W T F S
1234567
89 1011121314
15161718192021
22232425262728
293031    

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Oct. 21st, 2017 04:41 am
Powered by Dreamwidth Studios