Upgrading Fortify 4.40 to 16.1

[AspiringTFSGuru]

Has anyone attempted this yet? I'm actively trying in a test environment, but it's failing on seeding the database. I'll post more info here as I continue the process.

[AspiringTFSGuru]

Ok, so I was being dumb and inadvertently ran the migration database script against an old test database (v4.2). Once I ran the script against the correct test database everything went fine.

On a different note, if you're using LDAP, you will not be able to configure it through the configuration wizard. You'll need to login to the portal with a different account that has rights to finish the configuration. Just something to keep in mind.

[vtimoney1]

Hi Steve,

I'm trying the same thing(kind of) upgrading from 4.2 to 16.10. I upgraded the DB from Oracle version 11.2 to 12.1 & was told that it was simply a matter of running the configuration wizard(& migration.sql) to create a new war and drop it into tomcat(this hasn't worked!).

I have seen an ERROR around the ldap.properties when it's attempting to deploy so I re-ran the wizard & unchecked the 'Enable LDAP Integration' and recreated a new war, however it fails to deploy fully & falls over at a Quartz exception:

[ERROR] com.fortify.manager.service.scheduler.SchedulerService - Unable to start the Quartz scheduler

org.quartz.SchedulerConfigException: Failure occured during job recovery.

  at org.quartz.impl.jdbcjobstore.JobStoreSupport.schedulerStarted(JobStoreSupport.java:692) ~[quartz-2.2.1.jar:?]

  at org.quartz.core.QuartzScheduler.start(QuartzScheduler.java:567) ~[quartz-2.2.1.jar:?]

  at org.quartz.impl.StdScheduler.start(StdScheduler.java:142) ~[quartz-2.2.1.jar:?]

  at com.fortify.manager.service.scheduler.SchedulerServiceImpl.startScheduler(SchedulerServiceImpl.java:131) [ssc-core.jar:?]

  at com.fortify.manager.web.listeners.AppInitializer.startScheduler(AppInitializer.java:114) [ssc-web.jar:?]

  at com.fortify.manager.web.listeners.AppInitializer.start(AppInitializer.java:53) [ssc-web.jar:?]

  at org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:173) [spring-context-4.2.1.RELEASE.jar:4.2.1.RELEASE]

  at org.springframework.context.support.DefaultLifecycleProcessor.access$200(DefaultLifecycleProcessor.java:51)

I can't browse to the webpage as it is unavailable.

I'm using Centos 6/Java 8/Tomcat 8.

Anyone any ideas?

Thanks,

VT

[dandreica]

I have upgraded from 4.40 to 16.10 (on Windows 2012, Apache Tomcat and SQL Server) and encountered a serious regression in SSC. FPR files produced by SCA, when uploaded to SSC, get corrupted. The result is that source code is not displayed in SSC at all, and if one downloads the FPR containing source code from SSC and opens it in AWB, the source code is displayed garbled, i.e. many lines are just empty.

The issue is easy to reproduce. Given an FPR produced by SCA, opening it in AWB shows the source code associated with each vulnerability. When this FPR is uploaded to SSC and then downloaded back again, AWB displays just garbled source code.

A case opened with tech support has so far failed to identify a solution or workaround. I am curious if anyone here has had a similar experience.

[vtimoney1]

Hi,

Very interested in your post; I upgrading myself from 4.31 to 16.10(Centos 6/Apache Tomcat/SQL Server). Having major problems uploading an fpr file from cloudscan to ssc; it keeps giving out about SSLHandShakeException, even though my LDAP server is over ldap:// and I have all certs added to the keystore.

Just wondering if anyone else has seen this? I have also opened a case but no response yet.

Also, getting a LOT of random OutOfMemory errors, mainly on NodeJS apps but can happen intermittently.

[vtimoney1]

Note fixed this by running SQL statements for deleting these jobs in the 4.4 documentation. Will post if anyone wants them.

[AspiringTFSGuru]

Vincent, is the controller polling successfully with SSC?

[mfeferman]

Here's a silly question.

If you upgraded from v4.3x, did you make sure that the collation was changed to case sensitive for the new SSC database?

I would ask the same question of those at v4.4x, since I've seen people forget that step.

I just did a v4.31 upgrade to v16.10 with absolutely no issues at all.

[dandreica]

I haven't seen any SSLHandShakeExceptions, but our use case is an on-premise installation (we are not using cloudscan).

[mark.feferman@h]

Cloudscan is an on-premises component...it's just a misleading name...

[vtimoney1]

Yes it is now; it was an issue with the token authentication.