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

Upgrade to TeamSite 6.7.2 on windows

JoshProx

I am trying to upgrade from 6.7.1 to 6.7.2 on windows. This is the error which I get (Is there a way to upgrade to vannotate 1.2.0.0. separately) -

Product TeamSite Module "vannotate" failed at phase IW_INSTALL_MODE_PREINSTALL with the following errors: Module vannotate reported wrong version. Expected version is ==> 1.2.0.0, the reported version is ==> 1.0.1.1 STACK TRACE :java.lang.Exception: Module vannotate reported wrong version. Expected version is ==> 1.2.0.0, the reported version is ==> 1.0.1.1 at com.interwoven.install.module.Module.processSuccessXml(Module.java:1269) at com.interwoven.install.module.Module.getInstallResult(Module.java:1203) at com.interwoven.install.module.Module.install(Module.java:621) at com.interwoven.install.module.ModuleManager.executeInstall(ModuleManager.java:636) at com.interwoven.install.module.ModuleManager.fillGlobalPropertiesFile(ModuleManager.java:725) at com.interwoven.install.module.ModuleManager.doPreinstall(ModuleManager.java:259) at com.interwoven.install.product.Product.preinstall(Product.java:568) at com.interwoven.install.product.ProductManager.doPreinstall(ProductManager.java:210) at com.interwoven.install.installmgr.InstallManager.install(InstallManager.java:1366) at com.zerog.ia.installer.actions.CustomAction.installSelf(DashoA10*..) at ZeroGabm.run(DashoA10*..)

Find more posts tagged with

Comments

JoshProx

I've done some more analysis on this thing and found that the problem is with the workflow sub-system. Any of the workflow whether it's new job or default doesn't work and give this error:

[Sun Aug 31 15:33:48 2008] [error] [client 127.0.0.1] Premature end of script headers: iw_cgi_wrapper.cgi, referer: http://localhost/iw-cc/command/iw.group.submit
[Sun Aug 31 22:22:40 2008] [error] [client 127.0.0.1] Premature end of script headers: iw_cgi_wrapper.cgi, referer: http://localhost/iw-cc/command/iw.ccpro.new_job

I've checked the permissions with iw_cgi_wrapper.cgi and the user's have execute permission on it.

Any feedback on this?

Migrateduser

Be sure that you're installing as administrator. If so, then I would recommend filing a support case.

JoshProx

Thanks for the reply. I installed it with admin access. I checked the CGI impersonation settings in the release notes and added the following entries to the iw.cfg [authentication] section

impersonate_without_password=true
disable_ext_task_impersonation=true

It still didn't work after doing a iwreset -a. Do you think that we need to do any other setting for configuring the CGI impersonation? It seems to us that the CGI execution is failing on this server. Even the workflow instantiation CGI doesn't seem to work.

Migrateduser

A couple things I would try...
Try running the iw_cgi_wrapper.cgi from the command line and it should return some HTML.
The other is that there may be a problem with Apache executing CGI code. You may want to try browsing to http://localhost/iw-bin/show_env.cgi
If that also doesn't work, I'd lean toward an Apache configuration issue or possibly a permissions issue on the httpd or iw-bin folder or files.

JoshProx

Yeah I tried that. None of the cgi work on the server. This is what I see in iwui/access.log
127.0.0.1 - - [03/Sep/2008:20:09:29 -0400] "GET /iw-bin/iw_cgi_wrapper.cgi HTTP/1.1" 500 642 0 namit

and iwui/error.log says "Premature end of script header"

I have checked the file permissions under iw-bin and I have "Read and Execute" permissions for folder and file. What should I check on the apache front?

Migrateduser

Have you tried running any of the cgi's on the command line? You should make sure that works. Especially the iw_cgi_wrapper.cgi since this is a binary file. It could be corrupted. Copy a good version back into iw-home/httpd/iw-bin.

Migrateduser

I would strongly suggest working with support to resolve this, at this point. It seems that there is either a permission issue with your httpd/iw-bin directory or there is a configuration issue with iwwebd preventing it from executing CGI. When support resolves it, I would appreciate it if you could post the cause and result.

Thanks,

JoshProx

This problem is fixed. This was because of a wrong dll version under windows/system32

champs_rajesh

Hi,

Could you please share with me some important points about this Upgradetion.

What imp. things should we kept in our mind while doing this.

Thanks

Migrateduser

The solution to the case he is talking about is that his libeay32.dll in windows\system32 was out of date. By replacing it with the copy in \bin and rebooting the machine this fixed his issue. However, this is not something that happens to every machine. If you are seeing an issue similar to this and the above did not solve your problem then you will need to contact Interwoven Support as it might be something else that is causing the issue.

I'm currently looking into another custom's case that has the same type of issue but the libeay32.dll replacement did not solve it. I will post more as I uncover what the cause is.

Migrateduser

The customer I was working with came from 5.5.2 to 6.7.2. In 5.5.2 the iw-perl modules are stored in /iw-perl/site/lib/TeamSite. In the later versions of TeamSite (6.1 and above) they are in /iw-perl/vendor/lib/TeamSite. The error being displayed in the error.log was that the perl module iwconflictcheck.ipl called I18N_utils.pm and that did not contain the function iw_locale_2_lang.

[Mon Sep 29 15:06:09 2008] [error] [client 146.146.52.27] Premature end of script headers: iw_cgi_wrapper.cgi, referer: http://tuliwov02.citgo.com/iw-bin/iw_cgi_wrapper.cgi/iwwft_instantiator.cgi
[Mon Sep 29 15:06:09 2008] [error] [client 146.146.52.27] Undefined subroutine &TeamSite::I18N_utils::iw_locale_2_lang called at E:\\Interwoven\\TeamSite\\httpd\\iw-bin\\iwconflictcheck.ipl line 29.\r, referer: http://tuliwov02.citgo.com/iw-bin/iw_cgi_wrapper.cgi/iwwft_instantiator.cgi

The customer had both the old /iw-perl/site/lib/TeamSite structure and the new /iw-perl/vendor/lib/TeamSite sturcture. I had the customer shut off the TS services, copy over the custom pm modules they had in the /iw-perl/site/lib/TeamSite/PT folder to the /iw-perl/vendor/lib/TeamSite/PT then rename /iw-perl/site/lib/TeamSite to /iw-perl/site/lib/bad. Once the services were started again, TS used the correct pm modules in the /iw-perl/vendor/lib/TeamSite structure and everything worked.

I hope this helps with your upgrade issue.

Adam Stoller

The customer I was working with came from 5.5.2 to 6.7.2. In 5.5.2 the iw-perl modules are stored in /iw-perl/site/lib/TeamSite. In the later versions of TeamSite (6.1 and above) they are in /iw-perl/vendor/lib/TeamSite. The error being displayed in the error.log was that the perl module iwconflictcheck.ipl called I18N_utils.pm and that did not contain the function iw_locale_2_lang.

[..]

The customer had both the old /iw-perl/site/lib/TeamSite structure and the new /iw-perl/vendor/lib/TeamSite sturcture. I had the customer shut off the TS services, copy over the custom pm modules they had in the /iw-perl/site/lib/TeamSite/PT folder to the /iw-perl/vendor/lib/TeamSite/PT then rename /iw-perl/site/lib/TeamSite to /iw-perl/site/lib/bad. Once the services were started again, TS used the correct pm modules in the /iw-perl/vendor/lib/TeamSite structure and everything worked.

I hope this helps with your upgrade issue.

You seem to be a bit confused - the old structure was (if I remember correctly) iw-home/iw-perl/5.005_03/lib/site - the new structure is iw-home/iw-perl/{vendor,site}/lib - and custom modules should go into site/lib not vendor/lib - as vendor/lib may get overwritten during an upgrade or patch - whereas site/lib will not be overwritten.

If the modules didn't work in site/lib - then there was something else wrong.