Typical versus Custom TeamSite installation for v23.4.1
Hi,
was searching for an assessment of Custom v Typical TeamSite installation, and found the following thread for v16.x.
We'd like to ask similar for version 23.4.1, given that we only want to install TS & OD (not LS), and are not interested in using Site Publisher or Exp Studio, and our usage is not great. The one proviso we have is that we need to install everything under the /apps mount as that is where we have sufficient space (so can't use default locations like /iw-store). Other than that we'd like to keep it as simple and low-maintenance as possible, so our questions are:
- Can we use the 'Typical' installation given our needs, rather than the ~30 screen 'custom' extravaganza?
- Can we get away with using the bundled Postgres DB, or do we need to install another DB? Without LS the DB doesn't get written to much, to the extent that you wonder if it is really necessary, so can we just use the packaged Postgres even if it is a Prod installation (albeit it, not a very busy one)? I noted the comment about needing to set up an LS DB (and I seem to remember that 'feature'), has that been fixed?
Cheers
PJ
Comments
-
Dear PJ,
- Please refer to TeamSite 23.4 Planning and Installation guide, chapter 6.2.1 TeamSite Authoring components which explains the components distribution based on install mode (typical vs custom). Experience Studio component is mandatory. LiveSite Runtime component is optional.
- Embedded Postgres DB by the installer; it's not designed for production use - it's not scalable for larger environments. It's not a full-scale database like the one a customer can get from PostgreSQL Global Development Group company. For TeamSite 23.4.1 Production environments you can certainly use a Postgres DB of the following versions: PostgreSQL 13.8, 14 or 15 with driver postgresql-42.5.4.jar.
For this, you can follow the 2 chapters below from TeamSite 23.4 Planning and Installation guide:
-5.1 Create custom databases for TeamSite
-5.1.1 Supported databases
Thank you.
0 -
Hello Esmely,
from my reading, the biggest issue we would have with the 'Typical' installation is its seemingly mandatory placement of the content store at /iw-store. We need it under the /apps mount.
Is it possible, post-installation, to stop TS, change /etc/defaultiwstore to point to /apps/../iw-store, and restart? Or will references to /iw-store be embedded elsewhere in the software, for that not to work? We need to bring in our existing content store from the old data centre as a lift-and-shift (and I've recreated users/groups with same UID), so we are going to replace the newly installed store anyway.
Would like to keep it simple and use the reduced number of screens of the 'Typcial' installation if possible, as we have only very limited usage of our TeamSite implementation (and also why we'd like to use the bundled DB). However if that's not possible we'd then have to go for 'Custom'.
Cheers
PJ
0 -
You can change after the fact. It will likely create a new store in /iw-store but you can change defaultiwstore to /apps/iw-store (and NOT /apps/../iw-store as you entered).
BTW, I have not used the GUI installer for several years, preferring the silent installer. Once you have it working it is simple to reinstall.
As to Postgres, while it recommended to not use this in production, people do. If you are not using a runtime DB, via LiveSite, Search or DataDeploy, you can do this.
0 -
Thanks Nipper.
I meant a path under /apps (/apps/Interwoven/content/iw-store), was misleadingly using ".." to indicate that. I will give the 'Typical' installation a crack, then stop TS, move the store and change the store path in iw.cfg & defaultiwstore (hopefully that's all) and see if that works OK. Will report back on the result, to help anyone else who might want to do this - which seems likely as I don't think everyone would want the store directly under /, but would like to skip about 20 screens.
Takes a bit to set up X-Window for the GUI, but I find it helpful to have any errors pointed out in realtime, so I can fix without exiting.
Cheers
PJ
0 -
Yeah I get the immediate syntax checking, but I reuse my installer scripts (only making slight changes to bring it up to correct version). I also script updates of certain parameters so I can use the same template from Dev to Prod TS. After you do it a couple times, you will never go back to the GUI.
0 -
Ugh, 50 minutes of installing, then failed on "Configuring", ironically failed to install Postgres. Installer.log has:
"error: Failed dependencies:
lz4 is needed by postgresql15-15.4-1PGDG.rhel8.x86_64com.interwoven.wcm.install.util.InstallException: Unable to install Postgres at com.interwoven.wcm.datacontainer.install.tasks.container.linux.InstallPostgresOnLinux.installRpms(InstallPostgresOnLinux.java:208) ~[DataContainerInstaller.jar:Build 281]" etc
So I am left wondering if this can be fixed and we will be good to go, or if I have to uninstall and either get some dependency for PostGres, or install another DB, then try to install TS again.
Guess I need to create a Support ticket. Sigh.
//PJ
0 -
We might have to also….
First failure was on missing package lz4 (wasn't mentioned as a pre-req in installation doc). Installed that, reset the "InstallPostgresOnLinux" to completed in the installdocs file, restarted the Installer but it has crashed again.
This time it would appear to have crashed because it couldn't create 'postgres' user with useradd command and therefore could not setup Postgres.
And the reason would seem to be that we have a pre-existing AD user 'postgres' in our network, from another Postgres installation on another server, I presume. So useradd fails to create local user 'postgres' because that user exists in its eyes… The Linux session I was running the Installer from (in X-Window) actually prompted for "Current password" which I assume was for 'postgres' user, but I didn't notice it until the crash.
So this is a bit of bad luck I guess, although I wouldn't think it too improbable to have a AD 'postgres' user pre-existing in the network of a large company.
But how to get around this?
1. Trying to figure out if we can somehow remove that 'postgres' user just from our TS Linux server.
2. Or maybe enter the pw at the Linux Cl if we can find out what it is.
3. …any other alternative? Otherwise uninstall TS, install MySql and go again?
Yikes.
PJ0 -
I assume you have opened a ticket with support. They may be able to help, I have not heard any way to change the postgres user
If you choose to run with myqsl, the you will need to uninstall and remove everything. On Linux is it pretty straight forward, remove the new items in /etc and /etc/init.d and in the /apps/Interwoven (or appropriate) directory.
0 -
Just to finish this off, for anyone who is interested.
We could not get around the global pre-existing 'postgres' user, which to me is a downfall in the Installation script (try 'postgres1' then 2, 3 etc).
So I uninstalled TS, installed MySql myself, and ran a 'Typical' installation with that. That worked.
Then I stopped TS, moved /iw-store to under the /apps mount, and edited defaultiwstore & iw.cfg to reflect that (not sure which is used, iwgetlocation -a shows both), and restarted TS and that worked with the store in the new location.
I also tried to relocate the logs away from [iwhome]/local/logs the same way, but that didn't work for all. However I can live with that one, most important was being able to relocate the store to our most spacious mount after the 'Typical' installation.
Next thing will be to copy in our pre-existing content store from the old TS server. Using rsync or scp without root seems to mean I can't copy in as iwts:iwts (perhaps I need to apply a setuid & setgid on the dir I'm copying in to), so I think I will have some questions around that later - about best way to copy, setuid/gid, walkArchive.pl etc.
Cheers
PJ0
Categories
- All Categories
- 123 Developer Announcements
- 54 Articles
- 150 General Questions
- 148 Thrust Services
- 57 OpenText Hackathon
- 37 Developer Tools
- 20.6K Analytics
- 4.2K AppWorks
- 9K Extended ECM
- 918 Core Messaging
- 84 Digital Asset Management
- 9.4K Documentum
- 32 eDOCS
- 186 Exstream
- 39.8K TeamSite
- 1.7K Web Experience Management
- 8 XM Fax
- Follow Categories
- Docker Automation
- LiveSite Content Services (LSCS) REST API
- Single Page Application (SPA) Modules
- TeamSite Add-ons
If you are interested in gaining full access to the content, you can register for a My Support account here.
