Hi,
Our RT 5.0.3 installation logs the following warning to rt5.log:
Couldn't load custom field by 'CVE ID' identifier (/opt/rt5-poc/sbin/../lib/RT/Record.pm:2322)
I don’t see CVE IDs used anywhere in RT::IR and do not have a clue on what Custom field is to be loaded with that CVE ID. Could anyone shed some light on this?
Continuing on this monologue as well: it looks to me the upgrade from RT 5.0.1 to RT 5.0.2 fails to create the custom field ‘CVE ID’. At least there are definitions inside
/opt/rt5-poc/local/plugins/RT-IR/etc/upgrade/5.0.2/content
that look to me as targeted for the creation of a custom field called CVE ID. And when it does not get created, then all the related scrips fail. Hence, the odd warning in our rt5.log. I also tried to remove ‘CVE ID’ from CustomFieldGroupings in:
/opt/rt5-poc/local/plugins/RT-IR/etc/RTIR_Config.pm
/opt/rt5-poc/etc/RT_SiteConfig.d/RTIR_SiteConfig.pm
but this is apparently not enough.
A small nuance to the above: it’s probably the (global) Condition RTIR Merge that triggers this log warning since it is used by 4 scrips and when these then try to access the CF ‘CVE ID’ and there’s no such CF …
And more fun: accessing the GUI as admin and activating the Conditions menu (More → Admin → Global → Conditions), the admin user is offered a deletion button at the far end of the page saying “Delete selected conditions”. However, as far I can see there is no way to select any condition for deletion. One may click on a condition for looking at its meta data but still, it cannot be deleted.
Is our RT 5.0.3 installation broken somehow, or, is this deletion button available perhaps for custom conditions only created by ourselves or something else?
Was this an upgrade? RTIR seems to only support queues that are named ‘Incidents/Investigations/…’ so if you have queues with custom names upgrading to 5.0.3 throws a bunch of errors and doesn’t create the CVE ID custom fields for them (no idea why lifecycles aren’t used, those aren’t customer facing and seem a better fit for the logic than names that can’t even be localized without breaking things like Portlets). The workaround for us was to rename the queues back to their original names for the upgrade then rename them back, and just click through applies to for the CVE ID field for remaining queues.
The system conditions cannot be deleted it seems, if you create your own, they have the select checkbox next to them
Hi,
Yes, this was an upgrade all the way from RT 4.2.12 to RT 5.0.3. We did not have any custom queue names, unless “Systems administration” was such. This latter we disabled before starting the upgrade. The rest were normal RTIR or RT queues, all with default their names. Thus, I don’t know if our case matches exactly yours in this respect.
Based on your description, it might be worthwhile for us to try creating the ‘CVE ID’ custom field manually after our upgrade and see what happens. One question though: what queues does it apply to? To incidents, incident reports and investigations? Or should we also include countermeasures which seems to be the last of the obligatory queues in RTIR’s “quartet”? And a few more: what is its type? Enter multiple values, maybe? It applies to tickets I guess, but does it have a Validation regexp defined?
And thanks for confirming my suspicion the select checkboxes appear only for user created conditions, not the built-in ones.
{
Name => ‘CVE ID’,
Type => ‘FreeformMultiple’,
Queue => [ ‘Incidents’, ‘Incident Reports’, ‘Investigations’, ‘Countermeasures’ ],
Disabled => 0,
Description => ‘CVE ID for RTIR queues’,
LinkValueTo => ‘https://nvd.nist.gov/vuln/detail/__CustomField__#vulnCurrentDescriptionTitle’,
},
If the fields are not there, not sure if ‘make database-upgrade’ succeeded, not exactly sure what else it does, if you have a test machine might be worth rerunning it on it and checking if it throws any errors
Hi,
Thanks again. Up to RT 4.4.6 I used make upgrade-database from the source distribution (first the one for RT then the one for RT::IR). From there upwards I used rt-setup-database --upgrade to reach RT 5.0.3 as RT::IR has been integrated to RT 5.x series and is not a separately distributed plugin anymore.
It is claimed this rt-setup-database “is intelligent enough” to perform all upgrade operations. None of the make upgrade-database or rt-setup-database threw errors during the upgrade steps. Does this latter script fall short of the claim and should make upgrade-database be used from RT 5.0.3 instead, I don’t know. What was your upgrade path?
I was updating from 5.0.1 and just ran make upgrade-database from RTIR sources and following the upgrading doc:
Install the new version of RTIR. B<DO NOT> run C<make initdb>.
=item 5
Review all of the upgrade notes in docs/UPGRADING-*. If you were
coming from 2.6.1, you would read UPGRADING-2.6, UPGRADING-3.0, UPGRADING-3.2,
UPGRADING-4.0 and UPGRADING-5.0.
=item 6
Update RTIR's database.
Type:
make upgrade-database
Answer the prompt for which version of RTIR you are upgrading from. RT
will then confirm the upgrades that it is going to apply and will run
them in sequence.
Not sure about the ‘is not a separately distributed plugin anymore’ part, at least the latest README
https://docs.bestpractical.com/rtir/5.0.3/README.html
has standard steps of first install RT then with RTIR sources:
2) Run "perl Makefile.PL" to generate a makefile for RTIR.
3) Install any extra Perl modules RTIR needs that aren't already
installed. The output from the previous step will list new
modules needed, or if existing modules need to be upgraded to a
newer version.
4) Type "make install".
5) Activate the RTIR extension by putting the following line in your
RT's etc/RT_SiteConfig.pm file:
Plugin('RT::IR');
EDIT: or maybe you mean RTIR support has been added to the rt-setup-database tool, was not aware of that if that’s the case
Hi,
Thanks for questioning my assumption regarding “not a separately distributed plugin”: my (failing) memory played a trick here. It is the RT::Extension::REST2 that was separately distributed for RT 4.x and starting from RT 5.x, it is included in the RT 5.x software distribution (as RT::REST2). Another detail that contributed to my false assumptions is that starting from RT 5.x, the version numbering of RT::IR seems to go in sync with RT, i.e. RT 5.0.3 should use RT::IR 5.0.3.
So, I will revise my Makefile machinery when it comes to upgrading the database - out goes rt-setup-database and in returns make upgrade-database x 2. In other words, I assumed rt-setup-upgrade is capable of triggering the upgrade of RT::IR’s share of the database, but it looks like this is not the case. It probably only serves for upgrading RT’s part of the database.
After several install + db override + db upgrade iterations, it looks to me the amount of errors and warnings can only be reduced to a minimum by using the default settings (RT*_SiteConfig.pm) and if not possible, deviating from them as little as possible. Once the db upgrade is finished, one may reestablish one’s own original, tailoured production settings in the RT*_SiteConfig.pm files.
Considering the next future upgrade of the above, I would also assume that before starting the upgrade, one should yet again resort to using RT*_SiteConfig.pm files that deviate as little as possible from the default settings and reestablish the production settings once the process is over.