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; } } }

lscs sample Q

nipper

TS/SP/DS/CS 7.3.1 on Linux

I have loaded LSCS Authoring(1876) and CSRT (8080) I loaded the lscs-sample code. It deploys correctly and I can query CSRT by name/doc id/etc (but it does not respond on 1876)

The issue is the demo is not working and I cannot tell what server name/port the demo uses.

Application.data.js has the URI but not the main hostname/port. This is the press release demo.

Just curious where this information is stored.

Find more posts tagged with

Comments

Rick Poulin

What do you mean "it does not respond on 1876" if you can query it?

The information is stored in {uitk}/livesite_customer_src/etc/conf/livesite_customer/content.properties

nipper

What do you mean "it does not respond on 1876" if you can query it?

The information is stored in {uitk}/livesite_customer_src/etc/conf/livesite_customer/content.properties

I may have misconfigured something.

I installed LS Authoring on 1876 and RT on 8080. AFAIK, in 7.3.1 Authoring does not have a RT, so you need to query RT.

So I cannot query for a DCR on 1876 but it returns correctly on 8080 which is the RT. I can get diagnostics on 1876, but no projects are listed

I changed content.properties from localhost to the hostname. Something strange with my Linux install because ports on localhost are blocked (even though it is set correctly) so I cannot telnet to any high ports on localhost but can on hostname

Rick Poulin

I installed LS Authoring on 1876 and RT on 8080. AFAIK, in 7.3.1 Authoring does not have a RT, so you need to query RT.

Bwah? Those ports should be the other way around.. LSCSAuth is run by JBoss so it has to be on 8080 (unless you've actually gone through the headache of changing the JBoss ports). LSCSAuth does have a RT bundled in. What it doesn't have in 7.3.1 is its own embedded IDOL, as it now (inexplicably) assumes you've got TSSearch installed and wants to use that.

So I cannot query for a DCR on 1876 but it returns correctly on 8080 which is the RT. I can get diagnostics on 1876, but no projects are listed

Both Auth and RT sides should work exactly the same way. What happens is that in 7.3.1, they lobotomized the config file that defines which resources (URLs) are available in the LSCSAuth's runtime. This just doesn't work for me because my preview needs LSCS as much as my runtime does, so I've merged it with the 7.2.1 version. I can't imagine this was intentional on IWOV's part, because it's a dumber idea than assuming the client has search installed.
Path is Interwoven/LiveSiteCSAuth/runtime/webapps/lscs/WEB-INF/context/predefined-alias-context.xml

I changed content.properties from localhost to the hostname. Something strange with my Linux install because ports on localhost are blocked (even though it is set correctly) so I cannot telnet to any high ports on localhost but can on hostname

Do you perhaps have multiple NICs and it's only binding to one of them? The other thing I've seen before (albeit on Win2k8) is misconfigured IPv6 configs, where LSCS was binding to 127.0.0.1 only and my DNS routed localhost to ::1.

nipper

Bwah? Those ports should be the other way around.. LSCSAuth is run by JBoss so it has to be on 8080 (unless you've actually gone through the headache of changing the JBoss ports). LSCSAuth does have a RT bundled in. What it doesn't have in 7.3.1 is its own embedded IDOL, as it now (inexplicably) assumes you've got TSSearch installed and wants to use that.

Hmm, I thought I used the defaults, but I will recheck.

Both Auth and RT sides should work exactly the same way. What happens is that in 7.3.1, they lobotomized the config file that defines which resources (URLs) are available in the LSCSAuth's runtime. This just doesn't work for me because my preview needs LSCS as much as my runtime does, so I've merged it with the 7.2.1 version. I can't imagine this was intentional on IWOV's part, because it's a dumber idea than assuming the client has search installed.
Path is Interwoven/LiveSiteCSAuth/runtime/webapps/lscs/WEB-INF/context/predefined-alias-context.xml

Cool, I will look at this, it all started because I was trying to get the default WF working and it fails on the import.

They really need to clean the docs up on this.

Do you perhaps have multiple NICs and it's only binding to one of them? The other thing I've seen before (albeit on Win2k8) is misconfigured IPv6 configs, where LSCS was binding to 127.0.0.1 only and my DNS routed localhost to ::1.

Nope this is a Linux VM, I am really puzzled because it breaks OD as well. I cannot deploy to localhost 20014 but can to hostname 20014. Not a huge issue I use the hostname instead.

I may just dump my VM and start from scratch.