Setup/Background:
I work for a product that contains 500k+ LOC predominantly (Java and Javascript). We have been running Fortify static analysis roughly for the past decade since Fortify 3.x/4.x. We use SSC to view and audit the analysis results. That way, the results are also made available to others in the team who may be interested in addition to the security leads.
Periodically, along with the code release, Fortify version is also upgraded and the metrics are migrated to a newer version. Fortify platform and upgrades are managed by a separate team. We just run the scan, upload the fpr. The results are automatically merged in SSC. Subsequently, we audit the newly found violations and re-mediate them appropriately. Usually for every release, there are hundreds of false-positives which are audited as "Not an issue".
Question:
We are moving to a new platform - there would be a fresh installation of Fortify SSC managed by a different team altogether. If we perform an analysis and upload fpr to the new SSC instance, it may report one million+ violations. In reality, these violations have already been audited as 'Not an issue' in our existing instance. We need a way to "seed" the newer instance with audited results from older instance.
So, we would need some way to export the results from existing instance of Fortify SSC and import the same in the newer instance of Fortify SSC.
From the existing instance, I know that I can "Download Application File" fpr from 'Application Artifacts' that contains all the audited results. I would like to know if in the newer instance of SSC, by importing using 'Upload Artifact', will be audit data be seeded? So that, from the next scan, we can simply keep uploading the fpr files and the only the delta violations will be reported.
Existing Fortify SSC is on version 17.20. Newer platform Fortify instance would most likely be version 18.10 or 17.20 but hopefully not below that.
It should work, give it a try. If this doesn't work, I think you can directly export the Database from the old instance, and import it to the new Database. If the two SSC versions are two far apart, the database schema may have changed a lot and the data transfer may be challenging. If you have issues, I would contact Fortify Support directly for help. They are usually responsive.
TL;DR:
It works.
Long Answer:
I have "Downloaded the Application File" from an existing instance of Fortify SSC 17.20. This will typically be in the format - .fpr
I have installed another instance of Fortify SSC 17.20.
Later, I created a dummy Application and a Version for the project.
I have imported the earlier downloaded fpr from Step 1 using "Upload Artifact". Now, the new instance of SSC took 3 days to completely import and provide audit/metrics etc
Ensure that the audit/metrics are same as the source SSC instance
Subsequently, performed a fresh scan and uploaded the new fpr.
Fortify SSC successfully merged and the artifacts. On subsequent uploads the existing audits are carried forward and no information is lost.
Related
I copied the complete folder of my prestashop 1.7.3.0 on a new folder on my server with new database, install a new theme and maj prestashop in 1.7.7.0
The concern is that now that I have finished in the meantime I have had orders and customers.
I imported the products in excel redone the variations by hand.
How can I subsequently export customers and orders?
In excel import of my last clients it tells me that the password is required for the import?
What would be the best method even going on phpmyadmin to import the customers, addresses and orders that I miss on the new store?
Thanks for your feedback.
To align customers and addresses you can use Prestashop's built-in CSV import feature.
Regarding orders there is no standard way to do it,
you have to perform queries on the new database synchronizing the missing data of the old one, taking care to check the various tables of the site because there are several entities involved (and structure might change between PS versions too).
Also keep in mind that there may be third party modules on the old site that save data and therefore must be synchronized.
Other options: you'll put "catalog mode" on the live store for a few days until you've finished the work on the new one or use a paid data migration module that can perform incremental migrations.
I am trying two options.
One is not to store source code
If it is not possible how to delete project from sonar database?
I tried with "sonar.import Sources=false" but this is not working for sonar version 6.1(deprecated after 4.5 version).
If I delete the project,will source code remain in database?
Storage of source code in database can't be disabled because it's used to display data in webapp.
Source code is indeed dropped from db when deleting a project.
This is late, but might be helpful for someone:
Sonar usually cache the project for performance purpose via squid mechanism, then thru queue mechanism it stores the project data in internal h2 database which can be changed to few supported databases, then you will be having advanced options to manipulate data on database(things like fail-over cases can be achieved), not that I know of any way of not to store project data in database.
Unless you configure certain user, default user can be admin to sonar dashboard with password as admin, Login to console and navigate to Administration-> projects->Management, now delete n number of unnecessary projects. Once you do this Sonar dashboard will not be able to show the project again until you re-analyze same project. To make sure this worked,after re-analyzing project click on the project on dashboard and check the version under Activity.
Additional info: If you modify the maven project code, first build the project & then do sonar:sonar for latest modifications to be reflected.
I agree with other answer, elaborating in few lines..
I was given a database backup (with filestore), the filestore folder and another folder with the installed modules on that database.
I am expected to restore that backup in Odoo 8 with no more data. So what I did is create the PostgreSQL role who owns the database tables and give it enough permissions (login, createdb, replication). Then I created an Odoo config file. Inside this, I set this new PostgreSQL role in db_user and its password in db_password. I added the path where I stored the filestore in data_dir, and the path of the folder with all the modules in addons_path.
As I was given no launcher file, I copied the OCB folder of other Odoo instance I have and used its odoo.py file to start Odoo.
The new instance seems to run well, but now I have just restored the database, and I get this error:
QWebException: "'HttpRequest' object has no attribute 'endpoint_arguments'" while evaluating
'website.get_alternate_languages(request.httprequest)'
I was googling a lot but I was not able to find anything about it, except for a non-answered question in other forum.
Does anyone know what is this about?
Changes related to this issue were introduced in Odoo on 29 February, 2016 (I mean the following changes: [FIX] website: alternate languages translated URL and [FIX] website: backport of as you can check for now these changes are available in the official Odoo 8.0 code base as well).
So most probably you have used outdated Odoo 8.0 server that do not contain above mentioned fixes. Please update to the latest official Odoo 8.0 and check if the issue still persists. Normally your issue should disappear after the update.
When you move backup databases and you want to restore them later on, make sure you mark the branch and commit point of the server files that you took the backup from. I have taken a look at my local v8 odoo and I can see that the endpoint_arguments variable is initialised upon the creation of a web request (openerp/http.py class WebRequest around line 192.)
You mention though that you are restoring the database on the v8 OCB Odoo. If you navigate their distribution and on commit:
https://github.com/OCA/OCB/commit/3913667396e17075528108ac1031939e6f479ced#diff-5e2f434047c379642786a87195c806f9
you will see that this variable was missing and they have added it. So make sure that you git pull the server file to get that commit.
The root of the issue is that you took a backup from a server that had different codebase than the one you are trying to restore the database to. (The qweb file was searching for a variable that is not there)
I am in the process of setting up SQ for a large organization. I plan to have two separate systems one for update testing and rule development. The second would be the production system where real work occurs. I will be using SQL 2014 typically when I do that I use a SQL always On group to sync to a DR server in another datacenter. My question is with a SonarQube instance does it make sense to DR the application to that level. If my organization can wait for a period of time to stand up a new server in a DR event would that be possible with a proper backup of the DB? Further if there were no backups of the DB what would be lost with a fresh new SonarQube server besides setup/config time? Is there historical value of code scans that would be lost or would the next scan of the code base have us right back to where we were in terms of critical issues found etc.?
Thanks for your replies.
All the data is stored in the database so using DR on the database is a good idea. You should make backup of the database and restoring the database is also a good solution (note that you should do backup of installed plugins).
If you loose the database, you will also loose all the configuration (quality profiles, credentials, etc.) and the history of the analyzed projects.
So to restore a SonarQube instance, you have to :
Restore the database
Restore SonarQube or install the same version
Restore the plugins (${SONAR_HOME}/extensions/plugins)
During the first start, the ES files (${SONAR_HOME}/data/es) will be regenerated and you're instance will then be up and running.
If you have commercial plugins or if you are working with large SonarQube instance you may contact the sales team to have support on this setup.
Disclaimer : I'm working at SonarSource
Situation
Oracle APEX (version not specified)
Single Application
Administration Issue: Deployment of New App version.
Detail
The latest version is on Server1
End Users are actively working on an older version hosted on Server2.
How do I import the changes made on Server1 without impacting users who may still be working on Server2?
Some Basics on Deploying APEX App Upgrades
It's always good etiquette to warn users that an upgrade will be in progress. Give a few days advanced notice and a window of time you will need to accomplish the task. In this case, as I will explain, you can install your new upgrade and switch over to the new version quickly.
Use an Application Alias
Use an Application ALIAS to identify your application to get away from the arbitrary, sequence controlled ID.
This is where to identify an APP ALIAS
In this example, the Alias AND the ID can be used. I recommend to publish the ALIAS to the users and the support staff who make the little shortcut icons on everyone's desktop:
http://sakura.apex-server-01.guru:8080/apex/f?p=ALIAS
Where "ALIAS" is whatever you've assigned to the app (such as 'F_40788'). Aliases must be unique across an entire INSTANCE, or you can set up some clever redirects using Oracle's RESTful Web Service builder.
How to Switch Your Live Application to Maintenance Mode
The best way to avoid any unwanted DML or user activity from end users is to lock the front-end application right before you switch over to the new version.
This will prevent anything from changing the state of the data during the upgrade... in answer to the question, if a DML (insert, update, delete) activity initiates when the app is overwritten, either the transaction fails and rolls back because it didn't reach the COMMIT step.. or worse. You're better off just locking up for a few minutes.
How to Set an Application to Maintenance Mode
Rename your current version to the permanent ALIAS and archiving the one it replaced. It's better not to overwrite or immediately delete your older versions.
Multiple Versions Co-existing in the same Workspace:
It is equally as useful to check in the exported application definition scripts as they are encoded in UTF-8 plain text SQL. The benefit is that source code diffs can identify the differences between ver
As long as their access is restricted, and their alias changed to a unlisted value, they serve as a good fallback for any unanticipated issues with the new, current release.