Re: [rt-users] Bad name after cn' when using LDAPImport
That corresponds with this line of my RT_SiteConfig.pm: Look one line above that -- you appear to be missing a closing apostrophe. Set($LDAPGroupFilter, '(|(CN=dor-rt-admins)(CN=dor-rt-staff)); This is the offending line.
[rt-users] dashboard reminders in RT4?
Thank you, yes, I did skip that.I have now added it, and can see in my syslog, that it looks like it's running rt-email-dashboards. However, I am still not seeing any emails.No error messages in syslog around that entry, but no emails either. Any suggestion on where to look to debug (log, or )? On Thu, Aug 1, 2013 at 12:22 PM, Kevin Falcone falc...@bestpractical.com wrote: On Thu, Aug 01, 2013 at 08:26:38AM -0400, SSzretter wrote: I have set up a couple dashboards, which look good and also set a m-f 8am reminder with an email address in each.The email did not go out this morning, so I am trying to figure out why. Generally, emails go out for tickets and the system checks mail and pulls it in regularly, so I am assuming there is some kind of rt-crontool going on (or similar). I did not specifically set that up, but it's working. SO, there must be something additional that I have to do to actually have my dashboard reminders go out every day, what should I look at? You probably skipped step #9 in the install: http://bestpractical.com/docs/rt/latest/README.html -kevin -- Garden
[rt-users] Scripting ticket creation with fields containing non-alphanumeric characters.
I'm very new to RT and am trying to write a python script to create a ticket in my RT database. The crux of my problem lies in non-alphanumeric characters. Submitting the ticket works fine with all the fields that have only alphanumeric characters, but I have some fields with non-alphanumeric characters and those submissions return to me Error 409 Syntax Error. I am using python-rtkit to work with REST from my script. To try and solve this problem I have corresponded with the person who maintains python-rtkit to make sure that it wasn't a bug in python-rtkit or my misuse of the module (https://github.com/z4r/python-rtkit/issues/31 , you can find a copy of my script in this thread for reference). The conclusion reached at the end of that discussion was that I would need to upgrade my install of RT from its current version of 3.6.6 to 4.x. However I have discovered from my superior (who is in charge of our install of RT) that that isn't an option. After I tried that I tried to poke around and find some documentation on Error 409 but was unable to find any documentation of RT's errors anywhere but WAS able to find a correspondence for a similar issue (http://www.gossamer-threads.com/lists/rt/users/95179?search_string=REST%20syntax;#95179) unfortunately it is for a different version of RT (3.8.x) and the suggested fix involved a line in REST.pm that doesn't exist in my install of RT. Which brings me to posting in this mailing list. I'm wondering if there's a fix similar to the other one posted in the mailing list (see second link in this post) for RT3.6.6 that I can use to enable the creation of tickets via an external script without having to upgrade RT or remove those special characters I'm using RTv3.6.6 and the server is on Red Hat 4.1.2-54 and Apache 2.2.3. If you need any additional details, please ask. - The information contained in this message is privileged and confidential. It is intended only for the recipient or entity listed above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to the message and promptly deleting it from your computer. NOTICE TO RECIPIENT(S) OF INFORMATION: Information disclosed to you pertaining to certain conditions, such as treatment for alcohol or drug abuse, HIV/AIDS and other sexually transmitted diseases, behavioral health, and genetic marker information is protected by various federal and state laws which prohibit any further disclosure of this information by you without the express written consent of the person to whom it pertains or as otherwise permitted by such laws. Any unauthorized further disclosure in violation of state or federal law may result in a fine or jail sentence or both. A general authorization for the release of medical or other information is NOT sufficient consent for release of these types of information. The federal rule at 42 CFR Part 2 restricts use of the information disclosed to criminally investigate or prosecute any alcohol or drug abuse patient.
Re: [rt-users] dashboard reminders in RT4?
On Mon, Aug 05, 2013 at 06:48:50AM -0400, SSzretter wrote: On Thu, Aug 1, 2013 at 12:22 PM, Kevin Falcone falc...@bestpractical.com wrote: On Thu, Aug 01, 2013 at 08:26:38AM -0400, SSzretter wrote: I have set up a couple dashboards, which look good and also set a m-f 8am reminder with an email address in each.The email did not go out this morning, so I am trying to figure out why. Generally, emails go out for tickets and the system checks mail and pulls it in regularly, so I am assuming there is some kind of rt-crontool going on (or similar). I did not specifically set that up, but it's working. SO, there must be something additional that I have to do to actually have my dashboard reminders go out every day, what should I look at? You probably skipped step #9 in the install: http://bestpractical.com/docs/rt/latest/README.html Thank you, yes, I did skip that.I have now added it, and can see in my syslog, that it looks like it's running rt-email-dashboards. However, I am still not seeing any emails.No error messages in syslog around that entry, but no emails either. Any suggestion on where to look to debug (log, or )? The command you set up has several documented arguments to be used for testing and debugging: http://bestpractical.com/docs/rt/latest/rt-email-dashboards.html -kevin pgphAiDwpfNsd.pgp Description: PGP signature
Re: [rt-users] Scripting ticket creation with fields containing non-alphanumeric characters.
On Mon, Aug 05, 2013 at 01:27:33PM +, Green, Jesse wrote: I'm very new to RT and am trying to write a python script to create a ticket in my RT database. The crux of my problem lies in non-alphanumeric characters. Submitting the ticket works fine with all the fields that have only alphanumeric characters, but I have some fields with non-alphanumeric characters and those submissions return to me Error 409 Syntax Error. I am using python-rtkit to work with REST from my script. To try and solve this problem I have corresponded with the person who maintains python-rtkit to make sure that it wasn't a bug in python-rtkit or my misuse of the module ([1]https://github.com/z4r/python-rtkit/issues/31 , you can find a copy of my script in this thread for reference). The conclusion reached at the end of that discussion was that I would need to upgrade my install of RT from its current version of 3.6.6 to 4.x. However I have discovered from my superior (who is in charge of our install of RT) that that isn't an option. After I tried that I tried to poke around and find some documentation on Error 409 but was unable to find any documentation of RT's errors anywhere but WAS able to find a correspondence for a similar issue ([2]http://www.gossamer-threads.com/lists/rt/users/95179?search_string=REST%20syntax;#95179) unfortunately it is for a different version of RT (3.8.x) and the suggested fix involved a line in REST.pm that doesn't exist in my install of RT. Which brings me to posting in this mailing list. I'm wondering if there's a fix similar to the other one posted in the mailing list (see second link in this post) for RT3.6.6 that I can use to enable the creation of tickets via an external script without having to upgrade RT or remove those special characters 3.6.6 is more than 5 years old and has actually been End of Lifed for nearly 2 years now: http://blog.bestpractical.com/2011/09/rt-36-end-of-life-reminder.html You may want to talk to your supervisor again. There are a number of security issues in that release. The code you're running into was refactored before 3.8.0 was released, so any patch that was later applied to 3.8 or 4.0 to fix problems with the Custom Field parsing will be annoying to backport. As a result, I cannot just point you to a commit in git and tell you to apply it, someone would have to develop and backport a branch. -kevin pgpUmYcit_BqO.pgp Description: PGP signature
Re: [rt-users] One particular ticket crashes RT 3.8.7
On Mon, Aug 05, 2013 at 01:51:59PM +1000, Chris Herrmann wrote: [Mon Aug 05 12:58:24 2013] [notice] child pid 7013 exit signal Segmentation faul Set($LogToFile , undef); Set($LogDir, '/var/log/rt3'); Set($LogToFileNamed , rt3.log); #log to rt.log to RT_SiteConfig.pm but... there's nothing logging to /var/log/rt3 There's nothing in /var/log/rt3 because you told RT not to log anything to the file. You should touch /var/log/rt3/rt3.log and make sure your webserver can write to it and then change $LogToFile to the log level you want - however, you do seem to be getting debugging logs to syslog so you may not need it (logging the same debug log to multiple places just slows RT down). /var/log/debug contains: Aug 5 13:45:59 sirius RT: We found a merged ticket.106966/106648 Aug 5 13:45:59 sirius RT: We found a merged ticket.106969/106648 How many Tickets in your database have an EffectiveId of 106648? There's some performance improvements around merged tickets in 3.8.8. Usually when folks complain of crashing on old 3.8 tickets with lots of text, it's a bug in Text::Quoted or a bug in Perl. Those are both hard to fix without upgrades though. You would need a lot more information to show us what broke though. -kevin pgpYLoKIGVVIQ.pgp Description: PGP signature
Re: [rt-users] Bad name after cn' when using LDAPImport
That was indeed the failing line. Thank you. -Original Message- From: rt-users-boun...@lists.bestpractical.com [mailto:rt-users- boun...@lists.bestpractical.com] On Behalf Of Nathan Cutler Sent: Sunday, August 04, 2013 11:53 PM To: rt-users@lists.bestpractical.com Subject: Re: [rt-users] Bad name after cn' when using LDAPImport That corresponds with this line of my RT_SiteConfig.pm: Look one line above that -- you appear to be missing a closing apostrophe. Set($LDAPGroupFilter, '(|(CN=dor-rt-admins)(CN=dor-rt-staff)); This is the offending line.
[rt-users] LDAPImport succeds with user LDAP bind but fails with group
Continuing onwards with my attempt to pull groups and their members from Active Directory into Request Tracker I've made some progress. However, I'm currently stymied - LDAPImport will successfully connect and search for users but when re-using the LDAP connection it fails to connect for the group search. Here's the debugging information from an rtldapimport run: Running test import, no data will be changed Rerun command with --import to perform the import Rerun command with --debug for more information connecting to ldap://domaincontroller.alaska.gov binding as CN=dor-requesttracker,OU=Security Groups and Accounts,OU=IT,OU=Divisions,OU=DOR,OU=State Departments,DC=soa,DC=alaska,DC=gov searching with: base = 'OU=Security Groups and Accounts,OU=IT,OU=Divisions,OU=DOR,OU=State Departments,DC=soa,DC=alaska,DC=gov' control = 'Net::LDAP::Control::Paged=HASH(0x524cd80)' filter = '((cn = users))' search found 0 objects No results found, no import Testing group import searching with: base = 'OU=Security Groups and Accounts,OU=IT,OU=Divisions,OU=DOR,OU=State Departments,DC=soa,DC=alaska,DC=gov' control = 'Net::LDAP::Control::Paged=HASH(0x86973b8)' filter = '(|(CN=dor-requesttracker-admins)(CN=dor-asd-rt-staff))' [Mon Aug 5 17:10:47 2013] [error]: LDAP search failed Can't contact LDAP server (/usr/local/share/request-tracker4/plugins/RT-Extension-LDAPImport/lib/RT/Extension/LDAPImport.pm:1237) LDAP search failed Can't contact LDAP server search found 0 objects No results found, no group import Finished test Looking at the perl for LDAPImport.pm shows me that the _run_search method is generating the LDAP search failed part of the debugging output. I'm assuming this means that Net::LDAP is generating the Can't contact LDAP server from $result-code. I feel this hypothesis is further supported by the fact that a 'grep contact LDAPImport.pm' turn up nothing. It looks like Net:LDAP just gets the base and filter and off it goes. I've confirmed that my filter works with ldapsearch. I there something different I need to do get a successful LDAP bind when looking performing the group import? --- Kevin Elliott Networking Specialist II Alaska Department of Revenue, ASD-IT (907) 465-2314
Re: [rt-users] LDAPImport succeds with user LDAP bind but fails with group
Hi Kevin, I’ve confirmed that my filter works with ldapsearch. Can you send the working ldapsearch command? Seems suspicious to me that the initial search for the user comes up empty.
Re: [rt-users] LDAPImport succeds with user LDAP bind but fails with group
On Mon, Aug 05, 2013 at 05:45:58PM +, Elliott, Kevin C (DOR) wrote: [Mon Aug 5 17:10:47 2013] [error]: LDAP search failed Can't contact LDAP server (/usr/local/share/request-tracker4/plugins/RT-Extension-LDAPImport/lib/RT/Extension/LDAPImport.pm:1237) LDAP search failed Can't contact LDAP server Looking at the perl for LDAPImport.pm shows me that the _run_search method is generating the LDAP search failed part of the debugging output. I'm assuming this means that Net::LDAP is generating the Can't contact LDAP server from $result-code. I feel this hypothesis is further supported by the fact that a `grep contact LDAPImport.pm' turn up nothing. It looks like Net:LDAP just gets the base and filter and off it goes. I've confirmed that my filter works with ldapsearch. Correct - those errors come from Net::LDAP-error(). What do the logs on your LDAP server say? -kevin pgph0HD7HN_pD.pgp Description: PGP signature
[rt-users] [rt-announce] RT for Incident Response 3.0.0 Released
RT for Incident Response 3.0.0 is now available. Learn more about using RT for Incident Response http://www.bestpractical.com/rtir/ http://download.bestpractical.com/pub/rt/release/RT-IR-3.0.0.tar.gz http://download.bestpractical.com/pub/rt/release/RT-IR-3.0.0.tar.gz.asc SHA1 sums 6cc4797b185530bb050eefb68c1e15900714a8e9 RT-IR-3.0.0.tar.gz 5f1bd4bfd353956f2a714428773d373c1af7a1b1 RT-IR-3.0.0.tar.gz.asc RTIR 3.0 is fully compatible with the RT 4.0 series. It takes advantage of many new native RT features to remove complexity and ease future development. RTIR now uses RT's built-in IP Custom Field support, providing IPv6 support as well as IPv4. It can leverage RT's full text indexing support for faster searching of tickets. It also picks up many other new RT 4.0 features such as email history folding, autocompletion of email addresses, an online theme editor and continued support for PGP encryption/decryption of emails. You can read more about RT 4 features here: http://bestpractical.com/rt/whats-new-in-4.html RTIR now allows you to link Reports, Investigations and Blocks to multiple incidents and to require an Incident while creating a Report, Investigation or Block. This is controlled by the new %RTIR_IncidentChildren configuration option. By default, it retains compatibility with the RTIR workflow available in 2.4 and 2.6. As a result of this change, RTIR now provides greater flexibility for choosing an Incident during creation or linking. RTIR no longer ships an internal SLA implementation. RT::Extension::SLA is more flexible and supports more options. RTIR now allows greater editing of the searches displayed during Incident reply or during linking/splitting actions. A user can pull in resolved tickets or limit to a certain subset of the linked tickets. This RTIR release requires RT 4.0.14, but we recommend installing the latest RT release available (4.0.17 at this time) as it repairs a few regressions in the upgrade path. If you are already running 3.0.0rc1, this release contains a database upgrade. If you are still running on 2.4 or 2.6 but have been testing upgrades, it includes a number of updates to the upgrade process that should improve performance. Please review all of the documentation in docs/UPGRADING and corresponding docs/UPGRADING-* files relevant to your current RTIR version. You may also review the upgrading documentation at http://www.bestpractical.com/docs/rtir/3.0/ With the release of RTIR 3.0.0, the RTIR 2 series has officially entered maintenance mode. For more details about this and future RTIR release scheduling, we have published a blog post: http://blog.bestpractical.com/2013/07/rtir-release-scheduling.html A complete changelog is available from git by running: git log 2.6.1..3.0.0 or visiting https://github.com/bestpractical/rtir/compare/2.6.1...3.0.0 pgpHfL3_sA_pA.pgp Description: PGP signature ___ rt-announce mailing list rt-annou...@lists.bestpractical.com http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-announce
[rt-users] custom fields on dashboard for new tickets?
Hi AllCould someone point me in the right direction of how we would go about creating bullets and other custom fields for the front dashboard that is used by customer who create tickets? We'd like to create bullets and fields (that are mandatory to choose at least one), for say printersnetworkhardwaremonitorapplication, etc., to have the user click on when they create a ticket, and that info would be sent to the owner of the ticket so they could work on it.Thank you for any help you can provide in doing this!-Rick
Re: [rt-users] rt-users Digest, Vol 113, Issue 9
Hi Kevin, Thanks for that, yes I'm a bit blonde undef would not log. I've changed that to 'error' now. OK, there's 3 tickets with that effectiveID; there are 91 transactions that relate to those three ticket IDs. OK i've just tried the cli, and show ticket/106648/history works OK... and the www interface is working OK right now too for that ticket. Hmm... What kind of information do I need to dig out for you? Sorry a bit vague I know, I'm just not sure where to look for the information that's going to give a clue about what broke! so the logs when it does work look the same as when it fails: Aug 6 09:53:02 sirius RT: We found a merged ticket.106966/106648 Aug 6 09:53:02 sirius RT: last message repeated 2 times Aug 6 09:53:02 sirius RT: We found a merged ticket.106969/106648 Aug 6 09:53:02 sirius RT: last message repeated 2 times Aug 6 09:53:02 sirius RT: We found a merged ticket.106966/106648 Aug 6 09:53:02 sirius RT: We found a merged ticket.106969/106648 Aug 6 09:53:02 sirius RT: We found a merged ticket.106966/106648 Aug 6 09:53:02 sirius RT: We found a merged ticket.106969/106648 Aug 6 09:53:02 sirius RT: We found a merged ticket.106966/106648 Aug 6 09:53:02 sirius RT: We found a merged ticket.106969/106648 Aug 6 09:53:02 sirius RT: We found a merged ticket.106966/106648 Aug 6 09:53:02 sirius RT: We found a merged ticket.106969/106648 Aug 6 09:53:02 sirius RT: We found a merged ticket.106966/106648 Aug 6 09:53:02 sirius RT: We found a merged ticket.106969/106648 Aug 6 09:53:02 sirius RT: We found a merged ticket.106966/106648 Aug 6 09:53:02 sirius RT: We found a merged ticket.106969/106648 Aug 6 09:53:12 sirius RT: We found a merged ticket.106966/106648 Aug 6 09:53:12 sirius RT: last message repeated 35 times Aug 6 09:53:12 sirius RT: We found a merged ticket.106969/106648 Aug 6 09:53:12 sirius RT: last message repeated 44 times Aug 6 09:53:12 sirius RT: We found a merged ticket.106966/106648 Aug 6 09:53:12 sirius RT: We found a merged ticket.106969/106648 Aug 6 09:53:12 sirius RT: last message repeated 11 times Aug 6 09:53:12 sirius RT: We found a merged ticket.106966/106648 If I comment right now I get in /var/log/user.log: Aug 6 09:55:07 sirius RT: About to think about scrips for transaction #971499 Aug 6 09:55:07 sirius RT: About to prepare scrips for transaction #971499 Aug 6 09:55:07 sirius RT: Found 7 scrips for TransactionCreate stage with applicable type(s) Comment Aug 6 09:55:07 sirius RT: About to commit scrips for transaction #971499 Aug 6 09:55:07 sirius RT: Committing scrip #7 on txn #971499 of ticket #106648 Aug 6 09:55:07 sirius RT: Calling SetRecipientDigests for transaction RT::Transaction=HASH(0x7f5fbc933c10), id 971499 Aug 6 09:55:07 sirius RT: Working on mailfield To; recipients are Aug 6 09:55:07 sirius RT: Subject: [myRT #106648] [Comment] B/F - Broken site#012From: Chris Herrmann via RT helpdesk-comment@sirius#012Reply-To: helpdesk-comment@sirius#012In-Reply-To: CCD0821AE781994EB8BAB510676B5EF50120CD129B79@mail.local#012References: RT-Ticket-106648@local#012 CCD0821AE781994EB8BAB510676B5EF50120CD129B79@mail.local#012Message-ID: rt-3.8.7-31323-1375746907-921.106648-7-0@local#012Precedence: bulk#012X-RT-Loop-Prevention: myRT#012RT-Ticket: myRT #106648#012Managed-BY: RT 3.8.7 ( http://www.bestpractical.com/rt/)#012RT-Originator: chris@local#012MIME-Version: 1.0#012Content-Transfer-Encoding: 8bit#012Content-Type: text/plain; charset=utf-8#012X-RT-Original-Encoding: utf-8 Aug 6 09:55:07 sirius RT: Removing deferred recipients from To: line Aug 6 09:55:07 sirius RT: Setting deferred recipients for attribute creation Aug 6 09:55:07 sirius RT: Working on mailfield Cc; recipients are (and more like this - truncating in the interests of brevity - let me know if you want a full dump but it looks like it's just iterating over several scrips determining who it needs to notify based upon the transaction). Aug 6 09:55:08 sirius RT: Committing scrip #26 on txn #971499 of ticket #106648 Aug 6 09:55:08 sirius RT: Committing scrip #29 on txn #971499 of ticket #106648 Aug 6 09:55:08 sirius RT: Found 0 scrips for TransactionBatch stage with applicable type(s) Comment Aug 6 09:55:09 sirius RT: We found a merged ticket.106966/106648 Let me know where else I should go digging, or more general info that I can / should provide you on our setup. Thanks again! Chris
Re: [rt-users] LDAPImport succeds with user LDAP bind but fails with group
Ah! That's it. I forgot to change and test the filter ($LDAPFilter) used for the User import - not enough coffee this morning, I guess. The example used in the documentation is not applicable to Active Directory. Changing it from '((cn = users))' to '((objectclass=person)(!(objectclass=computer)))' allowed the User import to run successfully followed by the Group Import. Thanks all! -Original Message- From: rt-users-boun...@lists.bestpractical.com [mailto:rt-users- boun...@lists.bestpractical.com] On Behalf Of Nathan Cutler Sent: Monday, August 05, 2013 10:20 AM To: rt-users@lists.bestpractical.com Subject: Re: [rt-users] LDAPImport succeds with user LDAP bind but fails with group Hi Kevin, I’ve confirmed that my filter works with ldapsearch. Can you send the working ldapsearch command? Seems suspicious to me that the initial search for the user comes up empty.
