Multi-user configuration of G2 desired...almost there
|
cab3
Joined: 2005-06-03
Posts: 11 |
Posted: Wed, 2005-06-15 03:09
|
|
I have recently installed the G2B3 code, and am attempting to create multiple user galleries. I've figured out how to successfully add multiple users and albums with the appropriate permissions, but this only gets me to part of the solution I'm looking towards. I've installed a single copy of the Gallery2 code in /usr/local/gallery2. I'm hoping that I can have a single binary install of the code, while having multiple "user" galleries set up that will share the binaries, but will, for all other aspects, be independent of each other. As things are now, on my test.bersche.com site, I have two albums created, one that I have admin to, and one that my friend has admin to. What I'd really like is to have each of us have our own virtual server set up so that requests to test.bersche.com only show my albums, and not Dave's, and conversely a request to otherhost.otherdomain.com will only show Dave's albums, and not mine. I'm really wanting to keep a single repository of the Gallery software that I have to update (since I'm the admin of the server), and that everyone else can use, without my having to go around and update software versions in a dozen places on the server. Suggestions very welcome as to how I can achieve this. Many thanks in advance! ---- |
|
Posts: 16504
See the README for information on 'multisite' installations. http://test.bersche.com/README.html
Also be sure to use the search function on this forum to search the G2 forums for 'multisite'
You may want to update to the latest nightly or CVS, information for obtaining either can also be found in the README.
Posts: 32509
you should not start using multisite with G2 beta 3.
We changed the multisite architecture since beta 3, that to say, it was improved and the way we do it now is icompatible to the old multisite architecture.
So please get the current nightly snapshot from http://galleryupdates.jpmullan.com and start the installer there.
btw: your single repository for the codebase (php is not compiled into binaries, it's just the source / codebase) should be reachable with a webbrowser. you could symlink your /usr/.../gallery2/ folder or alias it, but you'll have to run the G2 installer in a webbrowser.
Posts: 16504
Thanks for that valiant, I didn't know about that. I just knew there were some improvments.
One other thought in addition to Valiant's comments. You may want to have an additional install of Gallery, like a "dev" location. One where you do the upgrades at, make sure everything works then either copy it over or symlink it to that new location.
Occassionally, at least during the beta cycle. Config.php has needed to be changed during an upgrade and if URL rewrite gets modified you'll need to re-configure that module and make sure .htaccess file can be written too. I'm pretty sure both are needed for each instance of Gallery for each site.
This is something you definetly want to test and possibly may want to wait until finally release of G2 before you share it with users in a production environment. However, if they're just friends and not paying customers you have to worry about ticking off, it would be a good testing ground for G2 in a multisite environment and you could provide feedback to the devs ;)
Posts: 11
Thanks for the tidbits. I'll be darned if I can find any reference to multisite in the readme as indicated, but I'll take your word for it.
I've got no problem having a prod and dev install, and kind of like the idea, just having 30-40 individual installs of the gallery software for all the users seems a bit overkill, so I'm glad to see that Gallery2 has taken this into consideration from the basis.
As for providing feedback, be glad to do so, and I'll be going to get the latest codedrop now and see if I can get it going with multisite. I've also found that it's sometimes easier to tick of paying customers than friends, since I have less attachment to the customers, while friends expect you to move the world just for them because of said friendship. :roll:
Posts: 16504
Ah, you'll need to upgrade to a newer nightly, http://galleryupdates.jpmullan.com/
But friends forgive, ticked off customers don't pay you ;)
Posts: 46
Is there any documentation on moving to multisite from single site? The current Readme (from 17/06/05 nightly build) only gives directions on converting the old type of multi site.
I've been running one site quite happily in the root of one domain for a few months now (www.badgersnaps.com) and want to set up a separate gallery under a second domain but make use of the same database, g2data directory etc.
Posts: 32509
single to multisite is exactly like a normal multisite install.
just run the installer, read the multisite instructions in the multisite step and finish the installer.
foreach new multisite, just run the installer.
Posts: 46
Sorry, I don't get you.
Part of the intent of multisite is to have one codebase as well as one db etc yes?
So in that case, how do you run the installer for a second domain without having a copy of the code in that second domain's tree?
You can't run it under the first domain and point to a directory under the second domain's tree as, being web based, the process is only going to "see" the directroy structure under the first domain.
ie /home/default/domain1.com/user/htdocs/ contains gallery2 and the install subdir for domain1.com
/home/default/domain2.com/user/htdocs/ for domain2.
Neither's pages can be reached by the other domain name via a web browser.
Posts: 32509
goal of the multisite is to have a single codebase for an unlimited number of g2 installs.
each install needs its own g2data (storage) directory and each install needs its own db tables.
that means, you need to use a seperate db or a new g2 table prefix for each multisite install.
1. install the codebase in domain1.com/user/htdocs/gallery2/
2. a) for each multisite install, browse to domain1.com/gallery2/install/ with your browser.
2. b) in the multisite step, enter /home/default/domain2.com/user/htdocs/gallery2/ as the directory for the new multisite install
it doesn't ask for the url, it asks for the filesystem path.
Posts: 46
That's what I meant in my last post, filesystem OR url, nothing can be accessed outside of the directory hierarchy of the domain you are visiting in the browser at the time.
The checking part in the install script comes back with "Directory doesn't exist". And it certainly does :D (oh and I've just double checked it's writable too)
I'd suggest it would be a horrendous security hole if you could access the filesystem outside of your current domain.
Posts: 32509
if you are installing a multisite for domain x with a codebase on domain y, it's a fairly good assumption that you either administer both domains or that the admin of domain x trusts the admin of domain y.
you are willing to use the codebase that is managed on another domain, is there a bigger security risk than that?
bottom line: there's nothing like a multisite install, if there's no trust between the multisite owner and the codebase owner.
read the instructions in the multisite step: you have to either create the few files embed.php, index.php, main.php, ... and chmod them 777 during the multisite install and chmod them back afterwards, or the gallery2 has to be chmodded 777 during the install.
if you then still can't access this directory in the multisite step, you have a php open_basedir restriction in effect.
Posts: 16504
Apache could also be ran in a jailed environment on that server preventing access to any files outside of one account into another user's account.
He could be dealing with a permission/user account issue on the server itself.
edit: which is pretty much what you said ;)
Posts: 46
I guess. The lines I was thinking along though were a central code repository that isn't part of any one domain at all, but linked to from each one, like a library.
Just for the record though, the "instructions" on the multistep page, such as they are, need clarifying. There's nothing about creating files, just that they should exist in the desitnation directory, which implies copying them from somewhere, not creating empty ones.
And yes, open_basedir is restricted to domain1, the "master" domain, if you will, according to phpinfo. I've no idea why as it's deliberately not set in php.ini. Where on earth else could that be set?
nivekiam : Should have mentioned that :D Nah, not jailed. All 9 instances running under the same account (apache).
Posts: 46
Found it - vhost.conf
Added domain2 into domain1's open_basedir directive and away we go
Although I'm now getting
in the error log of domain2 when trying to run upgrade/index.php.
(badgersnaps.com is domain1)
Posts: 32509
if you wanted to use it as a central code repository, you could use symlinks (ln -s).
multisite is our technology that is independent of mod_rewrite or symlinks, you don't have to use it.
Posts: 46
I'd rather stick with the way you guys are going to be honest, if only for support reasons :D
domain1/upgrade/index.php throwing out the same error, obviously. Time for a CVS methinks.
Hmm no, that didn't work
Posts: 46
Fixed the main site (badgersnaps.com) by deleting the file system and redownloading nightly build but leaving db and g2data intact.
Then ran installer again and specified multisite dir for 2nd domain (flyingbadger.net). Exited after that step and went to run flyingbadger.net/multitest/upgrade/index.php and got
Posts: 46
Anyone?
Posts: 32509
have you still the old, intact config.php with all your db and storage configuration in the gallery directory?
Posts: 46
I have *A* config.php there obviously (in the parent site). However, I presume that was generated afresh when I deleted and restored the file system from a nightly build as mentioned above.
I presume the line you're interested in is
$gallery->setConfig('galleryBaseUrl', '');
Posts: 32509
grahamb, your goal is still upgrading an old standalone to an up to date multisite install, correct?
let the codebase installer (badgersnaps.com) write the config.php, main.php, index.php, upgrade/index.php, embed.php files of the multisite install flyingbadger.net.
for this, you have to enter the installer in badgersnaps.com, choose multisite, and advance up to the write config.php step. let it write config.php and then don't advance to the next step. instead, go to the multisite, it should automatically start the upgrader.
Posts: 46
Yep that's the goal. I think I see the problem - I've been quitting the installer after the multisite step, not getting as far as writing out a new config file.
I'll give that a bash, cheers
Posts: 46
Hmm..closer.
Left the installer after writing a new config.php and this time I had the front page of my parent site (badgersnaps) appear under the child site (flyingbadger) albeit with no pictures, just the album structure.
It didn't automatically go to the upgrader.
I manually ran the upgrader from the child site and it seemed to go through fine, although I couldn't upgrade any of the modules (all greyed out), presumably becuase they're up to date in my parent site), but when finished, nothing had changed. I still have the structure of my parent site with no images.
Plus all of the links are broken - even those for main.php which is a tad odd.
Just to reiterate, the parent site is running off a nightly build from a few days ago after deleting everything off the filesystem first, so it's clean.
Parent site is www.badgersnaps.com
Child site is www.flyingbadger.net/multitest/
Posts: 32509
grahamb, disable the url rewrite module in the the child site.
if it then works, install the module again and hit save in the rewrite configuration admin page.
Posts: 46
How do I go about that? I can't login on the child site or anything due to the links being snafu'd
I've had a look at the 4 files in the child site and they all (with the exception of config.php) simply calling files from the parent site.
I'm a little unclear as to how that can create an entirely separate gallery site.
Hang on - the broken links are looking for flyingbadger.net/main.php not flyingbadger.net/multitest/main.php
Does multisite expect the location of the gallery files to be in the same directory for each site?
Posts: 32509
that the 4 files of the child site just include files from the main site is perfect, as it should be.
so you can't access site admin -> modules?
the easiest fix:
activate url rewrite in your main install (the one that works) and then copy the .htaccess file from the main site directory to the multisite directory.
in the copied .htaccess file, you will have to replace /multitest/ with /
alternatively, try this:
in your multisite database, in the g2_pluginmap, edit the row
module rewrite 1
to be
module rewrite 0
in the table g2_factorymap
remove the row:
GalleryUrlGenerator RewriteUrlGenerator RewriteUrlGenerator modules/rewrite/classes/RewriteUrlGenerator.class rewrite N; 2
then go to multisite g2data/cache/module/_all/0/0/ and delete the files
GalleryFactoryHelper_loadRegistry.inc GalleryPluginHelper_fetchPluginStatus.inc
hope that helps
Posts: 46
Okie doke - I'll give it a try. Given there's a lot you typed there though, can you confirm you saw my edit about the path on the broken links before I give that a go?
And no, can't access admin->modules. URL rewriting already active for the main site too.
And when you say "multisite database", there is only the one db, ie the one specified in the parent site.
Posts: 32509
@database:
each install needs its own database tables. do you use the same database, but a different table prefix for each install?
@paths:
ah i see.
your old multisite install was in / and your new multisite install is in /multitest/. correct?
Posts: 46
@database
There's only one opportunity to specify database information - in the install in the first site. Or are you suggesting you run the installer and enter details for the second site THROUGHOUT the installer (up until config file is written) ? At present I've just been specifying second site in the multisite step, and leaving the other information alone, ie pursuant to the first site.
@paths
Kind of yes, but I think it's just semantics that's leading me to say "kind of". Site1, badgersnaps.com, is installed to the root, site2, flyingbadger.net, I'm attempting to put multisite in a subdir, ie multitest/ as I don't want it interfering with what's already at the root.
Posts: 32509
it really would have made it easier if you just ran the multisite install to the last step just once to see what it is supposed to do. but you don't have to do it now.
yes, each time your run the installer it asks for a new storage dir and a new database configuration.
but in your case, you wanted to turn an EXISTING standalone G2 into a multisite G2.
a long time ago, you installed this standalone G2. you have to remember which g2data dir and which database configuration you used at that time. when you run the installer up to the config.php write step again, you have to enter the same storage path and the same db config from the old standalone install.
and this storage path and database configuration cannot be the same as the one you used in the www.badgersnaps.com setup.
Posts: 46
Ok, reran the installer, putting in second site path in multisite step, path to a new g2data under site2 in storage step and changed the table and column prefixes in the database step to something new (so I could keep using the same db/user/password).
On finishing that, the second site generates this error on trying to run index.php and thus does not forward on to the upgrader :
Manually trying to run the upgrader forwards me on to site1's install process instead.
Posts: 46
Figured it out. The above is caused by the database tables not existing. The advice
which I've also seen elsewhere (in the multisite instruction I think), is incorrect as the database tables are created at the very end of the installer. So as you're specifying a new db (or alternative table prefixes) you need to complete the installer all the way through on multisite, THEN go and run the upgrader, not abort after config.php is written.
All is now working correctly
Posts: 32509
?? why do you use a new g2data path?
let me clarify a few things. please correct me if i'm wrong.
these are your g2 installs:
Parent site is www.badgersnaps.com
Child site is www.flyingbadger.net/multitest/
the g2 install at www.flyingbadger.net/multitest/ is old, it was working before you tried turning it into a multisite install. thus, you had a g2data directory and a database for it before you tried to do the switch.
the motivation of this exercise:
the install at www.flyingbadger.net/multitest/ has already a few items and titles etc. and you don't wanna lose the work you have put into it.
www.badgersnaps.com is newer. when installing it, you used a new g2data path and a new database or a new database prefix. you did not specify the g2data dir or the database config for this new install that you were already using for the other install. correct? this is important!
if you erased the database tables of the old install or erased the g2data dir of the old install, this whole exercise can be ended right now, because the data/install of your www.flyingbadger.net/multitest/ would be lost in this case.
that brings me to a question:
you understand that with multisite installs, you can't show the contents of a single gallery in two different websites. multisite doesn't do that. multisite is about sharing a single gallery2 folder, thus saving about the about 60mb a G2 install requires. you don't share photos / users with multisites.
Posts: 32509
all working? fine with me then.
Posts: 46
You told me too :
No, the parent site, badgersnaps, is the one that I've had for ages. Although I recently cleared out the filesystem and replaced it afresh with a nightly build. flyingbadger has never had a gallery involved with it until this exercise. So no, no g2data dir or db.
I think I see the confusion behind your first sentence now - you think I'm creating a new g2data for the second site that already had one?
Nope - as above, this is the new site. When I said I didn't want to interfere with root level stuff, hence the multest directory, I didn't make it clear, it's nothing to do with Gallery. My site has a main.php and index.php and so on, but nothing to do with Gallery.
No, badgersnaps is the parent site - the only one I've had gallery installed on until now.
No, I never erased badgersnaps's g2data or db.
Understand that perfectly. I wanted two instances of gallery, apparently totally unrelated from the front end, ie each website's gallery contents has no relation to each other. It's just the backend, from a maintainability point of view, is one and the same. Well the files are anyway.
No need to get the hump, I'm not arguing or having a go. Funnily enough I'm trying to clarify the directions for implementing multisite. On many instances it's been said to write the config.php then leave the installer and go to the upgrader in the new site. This is incorrect as the new database tables are not written.
Posts: 32509
Obviously we misunderstood us from the beginning.
All you wanted was setup a second G2 install using multisite.
Of course you need to just run through the whole installer using a new storage dir and new a db configuration. That's it.
The "abort after the config.php step" stuff was based on the assumption that you want to do something strange, i.e. that the second install already existed but you want to turn it into a multisite child.
Case closed, good
Where do you read in the readme or in the installer that a multisite has to abort the installation after the config.php step? Is anything unclear?
Posts: 46
I can't remember where I saw that other than this and another thread. I have a hunt around.