From: Steve S. <ste...@co...> - 2003-12-03 00:23:54
|
I finally got back to some OI work. So far I like it. I managed to install it and start morphing it into the intranet site I want over the weekend. Today I started down the package path. I think I did okay until package install time. After pass one, I realized a bunch of things I forgot. Rather than upgrade I tried to remove then reinstall the existing package. I followed the instructions that describe necessary manual file removal, etc. On the second install I get "already exists in the base installation repository" errors. Any idea what I missed? Or was removal just a bad idea I should stay away from? Also, I'm not always 100% clear in the docs on website_dir ... I created a base site directory in /usr/local/sites. I named a site after that that has a subdirectory. It appears that for package installs I want to reference /usr/local/sites, not /usr/local/sites/XXX, but I'm not always clear. I want the current packages to be available to all sites, even though it will just be one in the short term. Any help appreciated. -- Steve Sapovits ste...@co... |
From: Chris W. <ch...@cw...> - 2003-12-04 02:23:33
|
Steve Sapovits wrote: > I finally got back to some OI work. So far I like it. I managed > to install it and start morphing it into the intranet site I want > over the weekend. Today I started down the package path. I think > I did okay until package install time. After pass one, I realized > a bunch of things I forgot. Rather than upgrade I tried to remove > then reinstall the existing package. I followed the instructions > that describe necessary manual file removal, etc. On the second > install I get "already exists in the base installation repository" > errors. Any idea what I missed? Or was removal just a bad idea I > should stay away from? The latter. There's a catalog (for lack of a better word) of the packages installed to the repository at: $REPOSITORY/conf/package_repository.perl When OI complains about something already being installed, that's what it's checking. The repository was designed so that multiple websites could use it as a definitive source for packages, so it doesn't make sense to delete packages since other websites might still need them. That said, this design is a solution without a real problem, and OI2 does away with it entirely -- each website gets its own packages, and that's it. > Also, I'm not always 100% clear in the docs on website_dir ... I > created a base site directory in /usr/local/sites. I named a site > after that that has a subdirectory. It appears that for package > installs I want to reference /usr/local/sites, not /usr/local/sites/XXX, > but I'm not always clear. I want the current packages to be available > to all sites, even though it will just be one in the short term. Here are the players: base repository - maintains a copy of all packages installed to OI; this is where 'install_package' puts the files; (This is what you'd set the 'OPENINTERACT' environment variable to as a shortcut.) I normally create this in /opt/OpenInteract, but your layout may vary. website - all the packages (plus old copies) for a particular website; this is where 'apply_package' or 'upgrade_package' puts the files and metadata, and where your website actually runs from. I normally create these under /home/httpd with the site name as the directory (e.g., /home/httpd/mysite.com, /home/httpd/funyuns.com, etc.) Under the main site directory are the top-level OI directories: conf/, pkg/, html/, log/, etc. Each website is associated with a base repository from which it draws the package information when 'apply_' or 'upgrade_package' is run. So when you 'install_package' it gets put into the base repository and is then available to all websites associated with that repository. Does that make sense? Chris -- Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |
From: Stathy G T. <sto...@tu...> - 2003-12-04 15:34:44
|
Hi, I was wondering how other users were setting object 'permissions' for their application other than hard coding and/or setting in the config. As an example I would like to be able to dynamically assign certain groups object permissions. Will I have to create my own 'acl' type screens for doing this? What are the drawbacks to doing this other than complexity? |
From: Steve S. <ste...@co...> - 2003-12-04 18:58:50
|
Chris Winters <ch...@cw...> wrote: > The latter. There's a catalog (for lack of a better word) of the > packages installed to the repository at: > > $REPOSITORY/conf/package_repository.perl I got that one and it was (I think) still complaining. But I may have other issues ... > Here are the players: > > base repository - maintains a copy of all packages installed to OI; > this is where 'install_package' puts the files; (This is what you'd set > the 'OPENINTERACT' environment variable to as a shortcut.) I normally > create this in /opt/OpenInteract, but your layout may vary. > > website - all the packages (plus old copies) for a particular > website; this is where 'apply_package' or 'upgrade_package' puts the > files and metadata, and where your website actually runs from. I > normally create these under /home/httpd with the site name as the > directory (e.g., /home/httpd/mysite.com, /home/httpd/funyuns.com, etc.) > Under the main site directory are the top-level OI directories: conf/, > pkg/, html/, log/, etc. > > Each website is associated with a base repository from which it > draws the package information when 'apply_' or 'upgrade_package' is run. > So when you 'install_package' it gets put into the base repository and > is then available to all websites associated with that repository. > > Does that make sense? It makes sense, but I believe I screwed up. Some of the site directories you mention are one level up at the base site directory. I think I created the site, but then gave a site directory of the site base in subsequent oi_manage commands. But my site is working ... except for that removal. I'll have to poke around. Since it's a single site, I may have just done it that way. So I have /usr/local/sites. My site name (not real) is XXXX and I have a /usr/local/sites/XXXX with only a Stash.pm in it -- conf, html, logs, doc, data, cache, etc. are all under /usr/local/sites. Assuming I did screw up (probably a safe assumption 8-), how safe is it to move things where they belong? Or is it easiest to just re-run the site installation the right way? I have not changed a lot but I have changed some aspects of the site. I wouldn't want to lose those changes. I can manually change database entries if needed. -- Steve Sapovits ste...@co... |
From: Steve S. <ste...@co...> - 2003-12-04 22:43:48
|
I asked: > Assuming I did screw up (probably a safe assumption 8-), how safe is it to > move things where they belong? This was relatively easy. I do not appear to have broken anything. -- Steve Sapovits ste...@co... |
From: Stathy G T. <sto...@tu...> - 2003-12-04 15:52:25
|
Sorry about the previous messages wrong subject line ... >I was wondering how other users were setting object 'permissions' for >their application other than hard coding and/or setting in the config. As >an example I would like to be able to dynamically assign certain groups >object permissions. Will I have to create my own 'acl' type screens for >doing this? What are the drawbacks to doing this other than complexity? |