We have set of policies (security and license) in our jfrog instance and have enabled with watchers for our builds with these policies. So we have noticed that there vulnerabilities are shown in the security and license tabs after the xray scan and according to our policy settings the violations are populated. But its noticed that still some vulnerabilities and violations are showing with no fix version information on those items. So our management want to exclude those vulnerabilities\violations from list where we dont have proper fix version information. I tried multiple policy settings and it didn't help me.
Related
Recently I have been tasked to downgrade our BizTalk Non Production environment as it was running on BizTalk 2016 enterprise. After all the backups I then uninstalled BizTalk 2016 enterprise and installed Biztalk 2016 developer edition I then configured the BizTalk server to join the existing BizTalk databases for the Group and features such as SSO and Business Rules engine and finally I restored the master secret. I made sure that these features were part of the installation.
After that I opened the console everything seems to be in order except for when I import/export a policy
adding a policy
I restarted all the services I could think of, rule engine service, WMI, DTC, the server itself to no avail. I even checked the Business Rules Composer and I could see all our policies/vocabularies. I checked the Registry and I could see BizTalk and BusinessRules entries and couldnt find anything different from a working environment(the one I have not touched yet)
So here I am wondering if anyone have encountered this issue and how did you solve it?
The answer lies in this blog post that Colin Dijkgraaf have commented -
manishrules.wordpress.com
Root cause
The table dbo.adm_Group in the BiztalkMgmtDb - somehow the values for RuleEngineDBServerName and RuleEngineDBName disappeared when I uninstalled the BizTalk Runtime for the downgrade, even worse the DateModified column didnt get changed.
Fix
I inserted the values for the columns mentioned and its now fixed
I have an artifactory server, with a bunch of remote repositories.
We are planning to upgrade from 5.11.0 to 5.11.6 to take advantage of a security patch in that version.
Questions are:
do all repositories need to be on exactly the same version?
is there anything else i need to think about when upgrading multiple connected repositories (there is nothing specific about this in the manual)
do i need to do a system-level export just on the primary server? or should i be doing it on all of the remote repository servers
Lastly, our repositories are huge... a full System Export to backup will take too long...
is it enough to just take the config files/dirs
do i get just the config files/dirs by hitting "Exclude Content"
If you have an Artifactory instance that points to other Artifactory instances via smart remote repositories, then you will not have to upgrade all of the instances as they will be able to communicate with each other even if they are not on the same version. With that said, it is always recommended to use the latest version of Artifactory (for all of your instances) in order to enjoy all the latest features and bug fixes and best compatibility between instances. You may find further information about the upgrade process in this wiki page.
In addition, it is also always recommended to keep backups of your Artifactory instance, especially when attempting an upgrade. You may use the built-in backup mechanism or you may manually backup your filestore (by default located in $ARTIFACTORY_HOME/data/filestore) and take DataBase snapshots.
What do you mean by
do all repositories need to be on exactly the same version?
Are you asking about Artifactory instances? Artifactory HA nodes?
Regarding the full system export:
https://www.jfrog.com/confluence/display/RTF/Managing+Backups
https://jfrog.com/knowledge-base/how-should-we-backup-our-data-when-we-have-1tb-of-files/
For more info, you might want to contact JFrog's support.
I use JFrog XRay v1.10.1 with Artifactory v5.2.1 (both PRO versions).
I cannot found in the XRay documentation (and Google) how XRay automatically re-scan artifacts that have not changed in Artifactory when the vulnerabilities database is updated.
What is the re-scan policy followed by XRay ?
Thanks in advance :)
Xray keeps a graph of all the scanned component and the relationships between them, for example if a certain Java library is part of a war file.
When a new vulnerability is added to the database, Xray will check if the effected component appears in the dependency graph and if so will check how it impact the rest of the graph. For example if a debian package inside a Docker image is found to be effected Xray will also mark the Docker image as impacted. This is called impact analysis in the Xray terminology.
This is explained in the documentation in the watches section.
I'm wondering how other Artifactory Admins do that so here's my question:
We're starting to use Artifactory to manage our artifacts. Internal as well as external artifacts. The external artifacts are all available in an internal repository. This is so because of a conversion from a file based repository to Artifactory.
Now this is starting to cause issues and I'm wondering how others are managing the external dependencies? As an Artifactory Administrator I want to be sure that my developers only use artifacts which have the correct license so I don't want to have a "feel free to download everything from the internet" culture.
I want to provide some sort of a "whitelisted and approved" set of external Artifacts.
Is this possible using Artifactory OSS or do we manually download the artifacts from a remote repository and deploy it to our local repository?
Thank you in advance!
this can be done with writing a user plugin but it will require a PRO version of Artifactory. You can see here examples to a governance control plugin that was written in the past.
With OSS version you can't reject downloads of users based on license.
Hope that answer your question.
I am trying out a mashup of Alfresco and ProcessMaker. I intend to use Alfresco's document management capabilities over ProcessMaker.
Here is the scenario:
A user fills up a form in ProcessMaker and a file is uploaded in Alfresco.
I followed the wiki in this link. The problem is that, my result variable is always false. I also checked my input. I am able to access Alfresco via the address I provided, but it still does not work. I also ensured that the file exists in my directory.
Is there a way I can check (probably from logs or console) the error being returned by Alfresco or ProcessMaker so I can continue?
Alfresco is installed in a Japanese version of Windows 7.
Alfresco version is 4.2.c.
Process Maker version is 2.0.45.
I have no experience with ProcessMaker, but here's a couple of things you can try to investigate your issue:
inspect the network traffic between ProcessMaker and Alfresco (e.g. with Wireshark) to see if there's any hint available in the HTTP responses from Alfresco
enable DEBUG logs on Alfresco side
as far as I can see, ProcessMaker users Alfresco CMIS REST APIs to implement its triggers. Have a look at class.pmAlfrescoFunctions.php in ProcessMaker and try the calls yourself with some REST client (e.g. curl, Chrome REST console, htty)
This should give you an idea of what's going wrong in your case.
UPDATE
After reading that the Japanese language pack changed a folder name from "Sites" to "/サイト", and double checking the Alfresco triggers code, it's indeed the case that localized versions of Alfresco are not supported OOTB by ProcessMaker, which hardcodes "Sites" in its CMIS queries.
While the workaround provided by #nmenego would be enough in most cases, I opened a bug to ProcessMaker to let them know of the limitation.
I discovered that the problem was in the encoding used by my installed Alfresco. Instead of the default folder /Sites, the default directory was /サイト (sites in Japanese). Apparently, upon installation, the names of the default folders are translated to Japanese.
What I did was I added a folder named /Sites, and it all works now.
Of course, the points pointed out by skuro are all valid as well.
We just confirmed that this is a bug in the ProcessMaker connector triggers for Alfresco, thank you for reporting it.
I've just opened ticket 11003 in ProcessMaker's Main Support Portal for the developers to work on fixing it.
Please register for free in ProcessMaker's Main Support Portal in order to follow up on the resolution of this bug.
Best regards,
Arturo A. Robles
Customer & Partner Support Manager
Colosa Inc. - ProcessMaker