kareila: IT prepares you for a life of fighting with PCs nonstop. (sysadmin)
[personal profile] kareila
http://wiki.dwscoalition.org/wiki/index.php/MogileFS_setup

All of the information that was previously there assumed you had root on a Debian box. I've updated the page to document the steps needed to get it working for dreamhacks as well. (Until the next time things break, anyway.)

YOU'RE WELCOME.

Ahem.

That is to say, if you try using my instructions and run into problems, let me know!
sophie: A cartoon-like representation of a girl standing on a hill, with brown hair, blue eyes, a flowery top, and blue skirt. ☀ (Default)
[personal profile] sophie
As most people here will know, I'm the maintainer of the Dreamhacks service which allows you to have a Dreamwidth development environment quickly and easily.

Some people will also know that lately the reinstallation script hasn't been working for some time. It's been broken ever since the move to git and GitHub, and I recently put a check in there so that anybody trying to use it won't accidentally end up with an unuseable 'hack. (By the way, if anybody does have an unuseable 'hack because of this, please feel free to let me know and I'll gladly reinstall you by hand!)

Although it should be fairly easy to get the reinstaller script working again, I've been running into some issues that I'm not entirely sure how to address. If you have a Dreamhack account, please read inside the cut as this could quite possibly affect you.

My dilemma )
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
[personal profile] fu
I had some weird behavior on my computer (running Mac OSX), because we had an image file named Sinisteria.jpeg, and another named sinisteria.jpeg, so I committed a fix.

Depending on your OS, you may need to run an extra step next time you upgrade. You'll need this for Mac OSX for sure, I can't remember how Windows and Linux deal with case in filenames.

Pull in updates as usual. This will delete Sinisteria.jpeg (uppercase)

$ git pull

Updating ecc1d71..7cb6ab7
Fast-forward
htdocs/img/styles/paperme/Sinisteria.jpeg | Bin 786 -> 0 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
delete mode 100644 htdocs/img/styles/paperme/Sinisteria.jpeg


Then check if you accidentally deleted sinisteria.jpeg (lowercase)

$ git status
# On branch develop
# Changes not staged for commit:
# (use "git add/rm ..." to update what will be committed)
# (use "git checkout -- ..." to discard changes in working directory)
#
# deleted: htdocs/img/styles/paperme/sinisteria.jpeg
#


If you didn't see the "deleted: ..." bit, you're fine. No need to do anything more.

If you do see the "deleted:..." bit, then do this:
git checkout -- htdocs/img/styles/paperme/sinisteria.jpeg

Now check again to make sure that worked:
$ git status
# On branch develop
nothing to commit (working directory clean)


Done!
didactic_cudgel: (Default)
[personal profile] didactic_cudgel
So, My Ubuntu 10.10 OS went end of support back in April, and so I thought it would be so very wise to upgrade. The upgrade from 10.10 to 11.04 went swimmingly, everything was fine on 11.04 to 11.10 and then from 11.10 to 12.04, everything went kerblooie.

When apache tries to start, it blows up on (I think) loading the modperl.pl file. I get these errors:
Cut for ugly errors )
whobutdrew: (Peace)
[personal profile] whobutdrew
Now running on Ubuntu 11.04 x64.

Reinstalled, redownloaded, reconfigured, restored... I now have a live site. Mostly, as is my usual state when I am working with this code.

I get the same "Oops, something is broken!" message that I originally got back in the day when i started about 2-3 years ago. Past fixes were to change the @LANGS line in config.pl (already done) and the fact that my first DW foray was on an x86 server. (Boy, did I hvae my history wrong in my previous post.)

Here is the line from my Apache error log:

Invalid userprop opt_viewjournalstyle passed to preload_props. at /home/dw/cgi-bin/LJ/User.pm line 853.

I'm now having to run off, else I'd elaborate more on the code that it is pointing to.
whobutdrew: (Default)
[personal profile] whobutdrew
Hello again, DW!

In the event nobody remembers me, a few years ago I jumped on the DWagon and started to build my own server. It was running just swimmingly during that time... until I went and tried to clean up unneeded packages. Now the system is buggered (though I do have backups!)

When I reached for my install disc, I realized that it was Ubuntu 9.04x32. I remember being told back then that DW wasn't quite ready for 9.1 or x64. I'm guessing that this has changed by now.

So what is the current best/supported version of Ubuntu server to use as the underlying OS? And is it x64 ready?

Glad to see you guys are still kicking!
dreamatdrew: "Dreamwidth Irish Pub", overprinted on green around a pint glass with Celtic knotwork on it. (Pub)
[personal profile] dreamatdrew
So, I finally managed to get an up-to-date copy of DW's source, and went about installing.
And... checkconfig tells me no. "Timezone must be UTC."
This is from http://bugs.dwscoalition.org/show_bug.cgi?id=3785 , which specifically added the check because "[t]he code expects system time to be GMT or really weird things happen".

I do not function on GMT. Therefore, my computer does not function on GMT. Therefore, no DW install for me.

So, I did a LITTLE investigating. Unless I'm completely mistaken, the "gimmie GMT" time functions are already built in to core perl. So, it should be possible to hack out that little requirement. Yes, it'd be a lot of tediousness. But I'm thinking not actually all that hard.

Am I wrong here? Opinions plz?
denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)
[staff profile] denise
Found by AgentCooper in irc:

$LJHOME/cvs/LJ-UserSearch/install-into-ljhome, on line 24, points to $LJHOME/cgi-bin/x86_64-linux-thread-multi/.... ... but the file is actually x86_64-linux-gnu-thread-multi .

This is an upstream bug -- we don't have a local fork of that repository -- and so the information has been passed upstream. In the meantime, install issues revolving around this can be fixed by changing the name to be the proper location.
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
[personal profile] fu
So it looks like Six Apart on github has moved all their repositories to be under Say Media. This has the side effect of causing our update script to fail, because it's looking for the Data-ObjectDriver which is no longer there.

Fortunately this is easy to fix!

From the command line, run these commands:

cd $LJHOME/cvs/Data-ObjectDriver

# check the current URL. This should be git://github.com/sixapart/data-objectdriver.git
git config --get remote.origin.url

#update to the new URL
git config --replace-all remote.origin.url git://github.com/saymedia/data-objectdriver.git

# check that your changes made it through. Should now say git://github.com/saymedia/data-objectdriver.git
git config --get remote.origin.url

# now run the update as usual...
$LJHOME/bin/cvsreport.pl --update




This is a one-time fix. Only existing installations will need to do this; new installations will automatically have the correct repository in their configuration.
pauamma: Cartooney crab holding drink (Default)
[personal profile] pauamma
With some versions of perl modules installed systemwide (ie, not under $LJHOME), you can get the following warning message when running bin/upgrading/update-db.pl:
Name "Template::Namespace::Constants::BASEARGS" used only once: possible typo at /usr/lib/perl5/Template/Base.pm line 49.
You can safely ignore this message, and the update shoupd proceed normally. (If it doesn't, comment and we'll look at it closer.)
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.)
kareila: (Default)
[personal profile] kareila
This recent post brought to my attention the fact that it really ought to be simpler for sites using DW code in production to easily keep up with stable milestones of DW development, without having to look through all of our repositories for the most recent milestone tags. Besides, the milestone tags are tied to code pushes on dreamwidth.org and not necessarily an indication of stability!

I propose the following mechanism:

1. Add a "stable" tag to all of our shared repositories. We already do code freezes where we only put in changes to fix bugs that are uncovered immediately after a code push. When the code freeze is lifted, move the "stable" tag to the most recent milestone and leave it there until after the next push/freeze cycle. For example, the most recent cycle would have moved the stable tag from 0.21.2 to 1.0.1 once it became clear there would be no 1.0.2 needed.

2. Add a new site config parameter (something like DW_STABLE) that indicates whether a site is only accepting our "stable" changes.

3. Change the behavior of -update in bin/vcv to only update as far as the "stable" tag if DW_STABLE is set.
didactic_cudgel: (Default)
[personal profile] didactic_cudgel
I run a production DW-powered site and I want to keep it up to date with the latest code fixes and features.

In asking #dreamwidth-dev about following this procedure: http://wiki.dwscoalition.org/notes/Dev_Maintenance firefoxfey recommended that I find out what the latest post-release final tag is an update only to that tag to avoid getting untested dev features, but didn't know the procedure. I was advised to ask here and so I am :)

If I want to keep my code current, but reduce the chance of pulling down untested code, how do I find and limit code to the post-release final tag?

Also, Fey suggested making sure that I'm aware of any database changes. Are those announced separate from code pushes?
didactic_cudgel: (Hmmmm)
[personal profile] didactic_cudgel
When running the search-lookup worker in workers.conf, I encountered an error: "Can't locate LJ/UserSearch.pm in @INC (@INC contains: /home/dw/cgi-bin /home/dw/src/s2 /cgi-bin /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at bin/worker/search-lookup line 22.
BEGIN failed--compilation aborted at bin/worker/search-lookup line 22."

Line 22 of search-lookup is

"use LJ::UserSearch;"

There is a *folder* called LJ/UserSearch and it contains MetaUpdater.pm.
foxfirefey: A guy looking ridiculous by doing a fashionable posing with a mouse, slinging the cord over his shoulders. (geek)
[personal profile] foxfirefey
So, recently there's been a change to VCV to get it working with repositories we use that are in git, because the subversion emulation wasn't working so well anymore (I think). This means a bit of a different update process to get entirely current. First, if you're on Ubuntu and you don't have git installed:
sudo apt-get git-core

Also make sure that if you have a multicvs.conf in $LJHOME/cvs/local/cvs--remove it or merge any changes in. If you just copied the main over with the SVN(Data-ObjectDriver) line commented, they can just remove it or revert back to the main one (cp dw-free/cvs/multicvs.conf multicvs.conf). If you keep multicvs.conf overridden with one in local/cvs you'll miss out on further changes, so make sure that's something you need if you keep it.

Then:
cd $LJHOME/cvs
rm -rvf Data-ObjectDriver
cd vcv; hg pull -u; cp bin/vcv $LJHOME/bin
cvsreport.pl --checkout
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
[personal profile] fu
I just committed the code for updated Atom Publishing Protocol support.

Two things that you'll need to do to run this on your dev server:

1.) make sure that memcache is running. Otherwise duplicate-request-detection code doesn't kick in, and authentication will fail

2) make sure that the files are deleted from your live code area in $LJHOME. These modules are the old version; the new versions of the modules are already installed if you're using a 'hack, or would have been installed if you'd followed the directions in Dreamwidth Scratch Installation.

As a reminder, here's how to delete the files using cvsreport:

cd $LJHOME
for i in `bin/cvsreport.pl -n -1`; do rm $i; done
(restart your webserver)
naienko: (happiness)
[personal profile] naienko
I'm slow, I know.
Anyway, the update won't go. It says
Can't use an undefined value as a HASH reference at /dw/cgi-bin/DW/User/DVersion/Migrate8To9.pm line 40.
Compilation failed in require at /dw/bin/upgrading/d8d9-userpicrename.pl line 27.
BEGIN failed--compilation aborted at /dw/bin/upgrading/d8d9-userpicrename.pl line 27.

Plus, the update page no longer allows users to select a userpic for their entry, which I'm thinking is somehow related. nevermind, somehow that fixed itself. I don't know.
foxfirefey: A guy looking ridiculous by doing a fashionable posing with a mouse, slinging the cord over his shoulders. (geek)
[personal profile] foxfirefey
We've just checked in a code change that moves to a new data version. You can read instructions on how to update your database.

This change has been made to make icon renaming more efficient, so we can keep that feature.
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
[personal profile] fu
Hmm, it looks like there's been a lot of changes going on in the mogile repository right now -- after running an update, I get a warning that I can't start mogilefsd because I'm on the wrong database schema.

Heads-up in case anyone runs into the same thing -- I've rolled back to r1459 of mogile for now.
[personal profile] texasmath
A bit of background - I run a website serving a small but dedicated education community. I was running Ubuntu 8.04 and was successfully running a webserver hosting the website, phpbb forum, wiki, and a livejournal (using apache-perl on a different port) client for our group. My computer crashed during a bad rainstorm, and I took this opportunity to upgrade to Ubuntu 10.04. I've been able to restore the website, wiki, and phpbb forum, but wanted to get dreamwidth on, so I wouldn't have to use a different port.

Using the Scratch Installation, I can get dreamwidth exclusively to run correctly by using the "stage" file, but I lose all my other services (wiki/forum/other web pages.)

When I try to implement these commands in my virtual host, I run into a lot of issues.

My Virtual host block looks like this:

<VirtualHost *>
    ServerName example.org
    DocumentRoot /var/www/example.org/
    ServerAdmin webmaster@example.org
    ErrorLog /var/log/apache2/example.org_log
    CustomLog /var/log/apache2/example.org_log common
</VirtualHost>

<VirtualHost *>
    ServerName www.example.org
    DocumentRoot /var/www/example.org
    ServerAdmin webmaster@example.org
    ErrorLog /var/log/apache2/example.org_log
    CustomLog /var/log/apache2/example.org_log common
</VirtualHost>

<VirtualHost *>
    ServerName wiki.example.org
    DocumentRoot /var/www/example.org/wiki
    ServerAdmin webmaster@example.org
    ErrorLog /var/log/apache2/example.org_log
    CustomLog /var/log/apache2/example.org_log common
    Redirect permanent / http://www.example.org/wiki
</VirtualHost>

<VirtualHost *>
    ServerName forum.example.org
    Redirect permanent / http://www.example.org/forum/
    DocumentRoot /var/www/example.org/forum/
    ServerAdmin webmaster@example.org
    ErrorLog /var/log/apache2/example.org_log
    CustomLog /var/log/apache2/example.org_log common
</VirtualHost>

<VirtualHost *>
    PerlOptions +Clone
    ServerName journal.example.org
    DocumentRoot /home/dw/htdocs
    ServerAdmin webmaster@example.org
    ErrorLog /var/log/apache2/example.org_log
    CustomLog /var/log/apache2/example.org_log common
    PerlSetEnv LJHOME /home/dw
    SetEnv LJHOME /home/dw
    PerlPassEnv LJHOME
    SetHandler perl-script
#    PerlConfigRequire /home/dw/cgi-bin/modperl.pl
</VirtualHost>


This allow my webserver to serve all the pages, but doesn't render the bml correctly. When I uncomment the PerlConfigureRequire, I get the following error:


* Restarting web server apache2 Use of uninitialized value $LJ::HOME in concatenation (.) or string at /home/dw/cgi-bin/LJ/LJ/Config.pm line 74.
Use of uninitialized value $LJ::HOME in concatenation (.) or string at /home/dw/cgi-bin/LJ/LJ/Config.pm line 74.
Use of uninitialized value $LJ::HOME in concatenation (.) or string at /home/dw/cgi-bin/LJ/LJ/Config.pm line 74.
Use of uninitialized value $LJ::HOME in concatenation (.) or string at /home/dw/cgi-bin/LJ/LJ/Config.pm line 74.
Syntax error on line 92 of /etc/apache2/sites-enabled/000-default:
Base class package "CSS::Cleaner" is empty.\n (Perhaps you need to 'use' the module which defines that package first,\n or make that module available in @INC (@INC contains: /src/s2 /home/dw/cgi-bin/LJ /home/dw/cgi-bin /cgi-bin /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl . /etc/apache2).\n at /home/dw/cgi-bin/LJ/CSS/Cleaner.pm line 20\nBEGIN failed--compilation aborted at /home/dw/cgi-bin/LJ/CSS/Cleaner.pm line 20.\nCompilation failed in require at /home/dw/cgi-bin/HTMLCleaner.pm line 8.\nBEGIN failed--compilation aborted at /home/dw/cgi-bin/HTMLCleaner.pm line 8.\nCompilation failed in require at /home/dw/cgi-bin/LJ/S2.pm line 26.\nBEGIN failed--compilation aborted at /home/dw/cgi-bin/LJ/S2.pm line 26.\nCompilation failed in require at /home/dw/cgi-bin/LJ/LJ/S2.pm line 22.\nBEGIN failed--compilation aborted at /home/dw/cgi-bin/LJ/LJ/S2.pm line 22.\nCompilation failed in require at /home/dw/cgi-bin/Apache/LiveJournal.pm line 26.\nBEGIN failed--compilation aborted at /home/dw/cgi-bin/Apache/LiveJournal.pm line 26.\nCompilation failed in require at /home/dw/cgi-bin/modperl_subs.pl line 31.\nBEGIN failed--compilation aborted at /home/dw/cgi-bin/modperl_subs.pl line 31.\nCompilation failed in require at /home/dw/cgi-bin/modperl.pl line 49.\nCompilation failed in require at (eval 2) line 1.\n
[fail]




For the record, /home/dw/cgi-bin/CSS/Cleaner.pm exists, and is the same as this.

I know that virtual hosts are "discouraged" because the dreamwidth code can be memory and processor intensive, but this same system was able to handle 20-30 user accounts for our group.

Can anyone give me a clue how to tweak my virtual host to render the bml correctly?

I appreciate all the help you can offer!

TDP.

Profile

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

June 2017

S M T W T F S
    123
45678910
11121314 151617
18192021222324
252627282930 

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jun. 23rd, 2017 08:44 am
Powered by Dreamwidth Studios