nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Yikes - What did I do?

Adam Stoller

Environment[indent]TS/SP/LS/OD 7.2.1 on Linux with WebSphere[/indent]Problem[indent]I was trying to make sure the second app-server worked by itself before I went back to trying to get a fan-out working with two app servers, and got interrupted in the middle for a disk space issue.
When I got back to what I was working on I realized that somewhere I must have messed up a configuration file or two because now all the parameters being passed in to the odAdapter (for lscs/teamsite-areadiff) were null.
I thought it had to be the ODHOME/conf/lscs/lscs-authroing.xml file - but I can't figure out what I did wrong there.
I've attached a zip file with a cut of the odbase.log (a non-working deployment with parameters being passed in, and a non-working deployment with null parameters being passed in) and the lscs-authoring.xml (both slightly morphed to protect customer names and hostnames, etc.)

If someone can tell me either (a) what I did wrong in the lscs-authoring.xml file or what other configuration file would be involved in passing [null] paramters to the odAdapter - I'd really appreciate it. I hate leaving things more broken in the evening then they were when I started the day in the morning (sigh)[/indent]

Find more posts tagged with

Comments

rohit34582

Check the lscs-conf.properties.

Why does:

not point to the LSCS-Auth store??

Check the odnodes.xml...

Check the lscs.log and the deployment.log of LSCS to get further details on the errors.

Rohit

Adam Stoller

Check the lscs-conf.properties.

What is this file? Where does it live?

Why does:
<preview lscsContext="lscs" lscsRuntimeTransport="http" lscsRuntimeHostname="localhost" lscsRuntimePort="8080" destinationArea="/usr/LSCSRT-Store" destinationNode="LiveSiteRuntime_wip"/>

not point to the LSCS-Auth store??

I don't think we're actually using 'preview' at this time - there's no preview instance installed on the TS server (we're planning to try to implement a runtime-preview environment called "wip" - but I'm not there yet)

Check the odnodes.xml...

Check the lscs.log and the deployment.log of LSCS to get further details on the errors.

The odnodes.xml is, I believe okay, the only lscs.log I see is on the application server side - on one of the application servers, and that's 0-length.
(follow-up post coming with "new" details coming ...)

Adam Stoller

A little thread terminology[indent]

Rick Poulin

Obvious Question: What configuration file is being processed that is missing the "lscsContext" attribute in preview?

This (ODHOME/conf/lscs/lscs-authroing.xml) is the wrong path for this file and I have no idea how you got it there. The PLC is looking at IWHOME/LiveSiteCSAuth/etc/deployment/config/lscs-authoring.xml, which is where you'll also find the lscs-conf.cfg mentioned by rohit.

I don't think we're actually using 'preview' at this time - there's no preview instance installed on the TS server (we're planning to try to implement a runtime-preview environment called "wip" - but I'm not there yet)

In 7.2.1, you ARE using the preview (LSCSAuth) instance if you're using the PLC to push to LSCS, or you should be if you want it working properly. Which is why, as rohit pointed out, your <preview> node's target path should be something more like /usr/LSCSAuth-Store and destinationNode should be "localhost" (or whatever you called it).

rohit34582

Also check the content.properties file

Adam Stoller

This (ODHOME/conf/lscs/lscs-authroing.xml) is the wrong path for this file and I have no idea how you got it there. The PLC is looking at IWHOME/LiveSiteCSAuth/etc/deployment/config/lscs-authoring.xml, which is where you'll also find the lscs-conf.cfg mentioned by rohit.

Hmm - that's where I found it - but I did see that there was a copy in the path you mentioned too (sort-of, LiveSiteCSAuth is in IWHOME/.. - not IWHOME/, in fact I changed a path reference from that to the one in ODHOME/conf/lscs in the LiveSiteCSAuth/authoring/etc/deployment/config/deployment-source.properties file. Should all the references in there be pointing to the LiveSiteCSAuth/etc/deployment/config/ directory?

FYI - there is still no lscs-conf.cfg file in that directory - just:

using in-TeamSite previewing of Pages (we're planning / hoping on trying to handle that on the app servers as a "runtime-preview" kind of thing)FWIW - I may not have jumped far enough back in the server.log - it appears the first error occurs during AttachDependencies (see attached)

nipper

And tell the sys admin to fix the locate command on your server.

locate lscs-conf.cfg

will save a lot of time

Adam Stoller

And tell the sys admin to fix the locate command on your server.

locate lscs-conf.cfg

will save a lot of time

Actually - it seems to be working [now]:

% locate teamsite-areadiff.xml
/usr/Interwoven/LiveSiteCSAuth/authoring/etc/deployment/config/teamsite-areadiff.xml
/usr/Interwoven/OpenDeployNG/conf/lscs/FanOut_teamsite-areadiff.xml
/usr/Interwoven/OpenDeployNG/conf/lscs/Single_teamsite-areadiff.xml
/usr/Interwoven/OpenDeployNG/conf/lscs/teamsite-areadiff.xml
% locate lscs-conf.cfg
%

Still no lscs-conf.cfg file.
(and it doesn't appear to be on their PROD TS server either)

Adam Stoller

Also check the content.properties file

Ah! That might be the piece that I forgot to flip back to point to D2 instead of D3 - I'm going to rebuild the toolkit in about 5 minutes (have to let the developers get a bit of a heads-up) and then see if startdeploy.sh still works and if the WFM deploy works again.

If the latter is still broken, I'll start looking at those alternative configuration files as mentioned by rpoulin

(If I had been here from the beginning, I'd at least know what they changed from OOTB settings - but I wasn't - so I can only base my information on what I can find now)

Update: This does appear to be the primary culprit to my issue of rolling things back to work with D2 (I still have a few other issues but it's getting a lot closer now .... I hope)

nipper

Actually - it seems to be working [now]:

% locate teamsite-areadiff.xml
/usr/Interwoven/LiveSiteCSAuth/authoring/etc/deployment/config/teamsite-areadiff.xml
/usr/Interwoven/OpenDeployNG/conf/lscs/FanOut_teamsite-areadiff.xml
/usr/Interwoven/OpenDeployNG/conf/lscs/Single_teamsite-areadiff.xml
/usr/Interwoven/OpenDeployNG/conf/lscs/teamsite-areadiff.xml
% locate lscs-conf.cfg
%

Still no lscs-conf.cfg file.
(and it doesn't appear to be on their PROD TS server either)

actually I think it is lscs-conf.properties

you can do

locate lscs-c

and it will tell all the paths that contian that string

Adam Stoller

actually I think it is lscs-conf.properties

you can do

locate lscs-c

and it will tell all the paths that contian that string

Nope - still nothing.

%  locate lscs | egrep "\.(cfg|conf|config|xml|properties)" | egrep -v "(example|_de|_ja|\-dah|\-dih)" 
/usr/Interwoven/ApplicationContainer/server/default/deploy/iw-cc.war/META-INF/lscs-sample.docket.xml
/usr/Interwoven/ApplicationContainer/server/default/deploy/iw-cc.war/WEB-INF/conf/livesite/lscsproperties/development_plc_lscs.properties
/usr/Interwoven/ApplicationContainer/server/default/deploy/iw-cc.war/WEB-INF/conf/livesite/lscsproperties/lscscode.properties
/usr/Interwoven/ApplicationContainer/server/default/deploy/iw-cc.war/WEB-INF/conf/livesite/lscsproperties/production_plc_lscs.properties
/usr/Interwoven/ApplicationContainer/server/default/deploy/iw-cc.war/WEB-INF/conf/livesite/resources/lscs-resource-config.xml
/usr/Interwoven/ApplicationContainer/server/default/deploy/iw-cc.war/WEB-INF/conf/lscs-sample/deployment.properties
/usr/Interwoven/LiveSiteCSAuth/authoring/etc/deployment/config/lscs-authoring.xml
/usr/Interwoven/LiveSiteCSAuth/install/jboss/webapps/lscs-static/WEB-INF/web.xml
/usr/Interwoven/OpenDeployNG/conf/lscs/FanOut_commit-deploy.xml
/usr/Interwoven/OpenDeployNG/conf/lscs/FanOut_lscs-authoring.xml
/usr/Interwoven/OpenDeployNG/conf/lscs/FanOut_reset-project.xml
/usr/Interwoven/OpenDeployNG/conf/lscs/FanOut_rollback.xml
/usr/Interwoven/OpenDeployNG/conf/lscs/FanOut_teamsite-areadiff.xml
/usr/Interwoven/OpenDeployNG/conf/lscs/commit-deploy.xml
/usr/Interwoven/OpenDeployNG/conf/lscs/lscs-authoring.xml
/usr/Interwoven/OpenDeployNG/conf/lscs/reset-project.xml
/usr/Interwoven/OpenDeployNG/conf/lscs/rollback.xml
/usr/Interwoven/OpenDeployNG/conf/lscs/teamsite-areadiff.xml
%

rohit34582

Does it work after the content.properties change?

Adam Stoller

Does it work after the content.properties change?

Yes - I needed to fix that file, and change the "wip" directory directives back to the "non-wip" directives (because we haven't set up the servers to expect the other target directory yet - and we're a bit too short on disk space right now to do so) - and rebuild the toolkit (build.sh).

And, apparently, even though we're not using a "preview" environment, the WFM *does* go through the "preview" path -- it's just that (before I got here) the configurations were setup so that "preview" and "production" were identical.

So - I have a bunch of things to work through - including trying to change everything from D2 to D3 again to figure out what's not setup correctly on D3 - and then I have to:

documented - in a fashion that will hopefully be a lot clearer than what's currently in (or not in) the product manuals.I'm going to close the thread now because this specific issue is now resolved. I may add to one of my other threads or start another new one when I get back to trying to get the above tasks done.

Adam Stoller

actually I think it is lscs-conf.properties
you can do
locate lscs-c
and it will tell all the paths that contian that string

Okay - I found it/them on the 2nd appserver (D3) - it's the first appserver (D2) where "locate" isn't working - which I'm going to see about getting fixed.

On D3 I see two different copies:

Part of the reason I'm thinking the former is the one being used, besides the existence of "defaultProject" is that the former specifies /usr/LSCSRT-Store and the latter specifies /usr/Interwoven/LSCSRT-Store - and while both directories exist, there is nothing within the second one, but several subdirectories in the first (dating back to when I first started trying to get deployments to this box to work)So - is that a safe assumption, or is the second one a base version and the first one an override?I just want to make sure I don't waste time trying to fix / adjust the wrong file.

nipper

Well it is safe to say you are all messed up.

1st, re: locate, it needs a DB to be updated (the index of paths on the system, updatedb is the command, needs to be run as root). That is usually in cron job, run nightly or weekly.

Is LSCS run alone or is it part of WS ? I know that LSDS runs as under WS, but do not remember if LSCS did.

Looks like a regular LSCS install was done as well.

If you hit the LSCS admin URL, that should shed light on the setup.

Rick Poulin

Is LSCS run alone or is it part of WS ? I know that LSDS runs as under WS, but do not remember if LSCS did.

It can. I'd guess they installed LSCS normally, then copied the WAR to WebSphere and are running it from there. In which case yes, the former is used and the latter is not.

What you want to check though is how WebSphere is set up to redeploy the app. They might have set it up to use LiveSiteCSRT as the "source", which would mean that any changes in WS would be overwritten if ever they redeployed the app from the WS console. So even though only one file might be 'active', you'd probably want to make changes in both copies.

Adam Stoller

It can. I'd guess they installed LSCS normally, then copied the WAR to WebSphere and are running it from there. In which case yes, the former is used and the latter is not.

What you want to check though is how WebSphere is set up to redeploy the app. They might have set it up to use LiveSiteCSRT as the "source", which would mean that any changes in WS would be overwritten if ever they redeployed the app from the WS console. So even though only one file might be 'active', you'd probably want to make changes in both copies.

This sounds about right from what I can tell of the implementations here - I'll have to double check on the WS setup (unfortunately, I don't have access to the WS Admin / Management interface - so it becomes a bit of a "telephone" game, sigh)

Thanks.