RE: [Trac] Re: turning on trac post-commit script in trac v12.1, RHEL6
On Jan 24, 12:57 pm, HardyPottinger hardy.pottin...@gmail.com wrote: Hi, I attempted to e-mail this message earlier, but it was apparently from the wrong address, so I'm posting via the web interface instead. Apologies if this ends up producing a duplicate message. I've installed the version (v12) of Trac maintained by EPEL (Extra Packages for Enterprise Linux) for RHEL6. This is an upgrade for us, we've been using Trac for years, and this upgrade is from v11, also installed on RHEL (v5) via EPEL. A smooth upgrade from v11, for the most part, with the exception of the required changes to the post-commit configuration. I see from the wiki that I need to enable the CommitTicketUpdater plugin, and that this plugin is part of the standard installation of Trac, but must be enabled. I can confirm the commit_updater.py code is present on the system: locate commit_updater.py /usr/lib/python2.6/site-packages/tracopt/ticket/commit_updater.py /usr/lib/python2.6/site-packages/tracopt/ticket/commit_updater.pyc /usr/lib/python2.6/site-packages/tracopt/ticket/commit_updater.pyo I have added the following lines to our trac.ini file: ... [components] ... tracopt.ticket.commit_updater.committicketreferencemacro = enabled tracopt.ticket.commit_updater.committicketupdater = enabled ... [ticket] commit_ticket_update_check_perms = true commit_ticket_update_commands.close = commit_ticket_update_commands.refs = ALL commit_ticket_update_envelope = [] commit_ticket_update_notify = true ... And I've upgraded the post-commit hook script in the svn repository, so that it reads: #REPOS=$1 REPOS=/svr/svn/our_repository_name REV=$2 # e-mail a message detailing this commit /usr/local/path/bin/commit-email.pl $REPOS $REV --from ad...@mywork.edu -s commit: ourdevmaill...@mywork.edu # call the trac-post-commit-hook LOG=`/usr/bin/svnlook log -r $REV $REPOS` AUTHOR=`/usr/bin/svnlook author -r $REV $REPOS` TRAC_ENV='/svr/trac/ourrepository/' TRAC_URL='https://oururl/ourrepository' $REPOS/hooks/bin/trac-svn-hook\ $REPOS \ $REV \ $AUTHOR The $REPOS/hooks/bin/trac-svn-hook script was copied directly from /usr/share/doc/trac-0.12.1/contrib/trac-svn-hook First, the symptoms: * Commits are working as expected: messages are sent from the post- commit hook to ourdevmaillist * Commands in commit messages no longer update tickets in Trac. This used to work with our v11 installation of Trac. * The admin interface of our Trac site does not indicate that the plugin tracopt.ticket.commit_updater.committicketreferencemacro is enabled, nor that it's even an available plugin. So, I'm wondering if anyone else has successfully made a similar upgrade in a RHEL environment, and if so, would you be able to share the secrets of your success with me? Or, even if you're not working in this environment, if you have any tips for me, they'd be appreciated. Thanks! -Original Message- From: trac-users@googlegroups.com [mailto:trac-users@googlegroups.com] On Behalf Of HardyPottinger Sent: 25 January 2012 03:31 To: Trac Users Subject: [Trac] Re: turning on trac post-commit script in trac v12.1, RHEL6 I'm beginning to think I need to repackage the /usr/lib/python2.6/site- packages/tracopt/ticket/commit_updater.py code as an egg and park it in the plugins folder. This is just a guess at this point, and if anyone has a better hint for me, I'll take it. Otherwise, I'll keep plodding on. If I figure it out, I'll post to this list. Thanks! I use windoze but I do have the ticketupdter working. It appears in admin as a component of the Trac 0.12.x plugin, not as a plugin in its own right. Expand the Trac item and search for `commit` on the page... Also, did you disable the on-access synchronisation of repositories (using [trac] `repository_sync_per_request` option)? Also, the functionality was not in 0.11 yet you say it worked, do you have a separate plugin that needs to be removed/disabled? Hope that helps... ~ mark c -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] VCS hook control from Trac web admin?
On Mon, Jan 23, 2012 at 14:48, Olemis Lang ole...@gmail.com wrote: Hi ! On Sun, Jan 22, 2012 at 1:34 PM, Magnus Therning mag...@therning.org wrote: I've only found a plugin that allows editing of SVN hooks[^1], but it is unlikely to cut it in our organisation; having users editing scripts that are run on the server will not be well received by the system admins. So, is there some other plugin that gives the user some control (but not full) over the hooks, maybe something along the lines of how github handles hooks? Ideally it should also support both SVN and git. ... well ... I'm the maintainer of RepositoryHookSystemPlugin [1]_ - so far it works mostly in GNU/Linux i.e. better compatibility for Windows is needed - ... even if it's designed to support any type of VCS only SVN is actually implemented at the moment , and I was thinking of adding support for Hg . - it's written for 0.11 - in theory users should not be managing repository hooks, not even doing any other admin task (as they all require at least TRAC_ADMIN permission ;) , unless something like multi-project support is to be used and some users manage a project inside an environment . so my Qs are : - What's the target version of Trac ? 0.12 and later. - Target OS ? Linux - If I move its code to e.g. some Hg repository @ Bitbucket would you consider using that plugin as starting point for your work (rather than starting the whole thing from scratch ;) ? Absolutely, but see my comment below. - maybe you might want to add support in there for Git ;) Yes, git is an important target for me in the medium term. Now to my slightly longer comment after reading about the plugin you pointed me to. First, there are two admins in the system, the system-admin (or root) who has full access to the machine, and trac-admins who has admin rights only on a Trac instance. Beyond this there are also trac-users. Do note that there are no system-users in our setup. They way I understand your plugin it would most likely not be acceptable in our environment. Having trac-admins write scripts that get executed on the server is not something the system-admin will allow. (This is in the name of security, and I know that there are other garage-door sized wholes already, like the ability for a trac-admin to upload any plugin. But hey, I'm not keen on trying to push through an obvious way for trac-admins to run code on the server by pointing out that there already is another, less obvious, way to do just that. Not when that other mechanism is so useful to me as a trac-admin. :) No what I'm envisioning is a plugin that works a lot like github's hook functions. On github a set of hook functions are available to the repo admin to choose from. Which functions are available is controlled by the system-admin. A repo-admin then ticks the ones that she/he wants, with some configuration possible, like if a mail is to be sent on commit, where does it get sent, etc. This means the system-admin has full control of what code can possibly get run on the server, while the repo-admin can choose the functions that make sense for each repo. Adding a new function is a bit bureaucratic, but does allow the system-admin to stay in charge. The relationship between system-admin and repo-admins on github mirrors the relationship between system-admin and trac-admins in our organisation. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] VCS hook control from Trac web admin?
Quoting Magnus Therning mag...@therning.org: They way I understand your plugin it would most likely not be acceptable in our environment. Having trac-admins write scripts that get executed on the server is not something the system-admin will allow. (This is in the name of security, and I know that there are other garage-door sized wholes already, like the ability for a trac-admin to upload any plugin. But hey, I'm not keen on trying to push through an obvious way for trac-admins to run code on the server by pointing out that there already is another, less obvious, way to do just that. Not when that other mechanism is so useful to me as a trac-admin. :) Just to be sure: Does your Trac run under uid 0 (root)? This would be completely unacceptable, of course. If Trac runs as its own, separated user, the shell scripts still can do harm, but e.g. not kill the system. Uploading plugins can be easily prohibited by setting the plugin dir to 555, very simple. Btw. plugins are only stored in the plugins dir and cannot access data, that the trac user (hopefully not root/0) is not allowed to access. Cheers -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] VCS hook control from Trac web admin?
On Wed, Jan 25, 2012 at 7:23 AM, Magnus Therning mag...@therning.org wrote: On Mon, Jan 23, 2012 at 14:48, Olemis Lang ole...@gmail.com wrote: Hi ! On Sun, Jan 22, 2012 at 1:34 PM, Magnus Therning mag...@therning.org wrote: I've only found a plugin that allows editing of SVN hooks[^1], but it is unlikely to cut it in our organisation; having users editing scripts that are run on the server will not be well received by the system admins. So, is there some other plugin that gives the user some control (but not full) over the hooks, maybe something along the lines of how github handles hooks? Ideally it should also support both SVN and git. ... well ... I'm the maintainer of RepositoryHookSystemPlugin [1]_ - so far it works mostly in GNU/Linux i.e. better compatibility for Windows is needed - ... even if it's designed to support any type of VCS only SVN is actually implemented at the moment , and I was thinking of adding support for Hg . - it's written for 0.11 - in theory users should not be managing repository hooks, not even doing any other admin task (as they all require at least TRAC_ADMIN permission ;) , unless something like multi-project support is to be used and some users manage a project inside an environment . so my Qs are : - What's the target version of Trac ? 0.12 and later. ... well ... that been said , if you move forward this way then you should also be interested (as I am ;) in adding support for Trac=0.12 (which adds some extra-complexity e.g. multi-repos ;) . - Target OS ? Linux good ... though for Trac=0.12 the underlying reason making it not to work now in Windows should be gone (reduced ?) ;) - If I move its code to e.g. some Hg repository @ Bitbucket would you consider using that plugin as starting point for your work (rather than starting the whole thing from scratch ;) ? Absolutely, but see my comment below. btw ... check this out [2]_ (please contact me in private to grant your Bb user with write access to the patch queue ;) . We can hack a little and work on patches in there so as to experiment for a while without touching the main repos . If it turns out that something useful and generic is built in there then I can request an «upgrade» your status so as to to grant you with commit access to main repos ;) - maybe you might want to add support in there for Git ;) Yes, git is an important target for me in the medium term. :) Now to my slightly longer comment after reading about the plugin you pointed me to. First, there are two admins in the system, the system-admin (or root) who has full access to the machine, and trac-admins who has admin rights only on a Trac instance. Beyond this there are also trac-users. Do note that there are no system-users in our setup. common case ;) you should have more control over this once multi-project support will be ready ... but it's not yet They way I understand your plugin it would most likely not be acceptable in our environment. Having trac-admins write scripts that get executed on the server is not something the system-admin will allow. that's exactly the goal of the plugin , to implement components inside a Trac environment so as to allow for hook customization but without full access to VCS-specific hook machinery ;) (This is in the name of security, and I know that there are other garage-door sized wholes already, like the ability for a trac-admin to upload any plugin. ... if you allow doing this then you have a more serious security issue as this is something happening beyond the scope of the plugin itself . think about it this way : if you manage to prevent trac-admins from uploading plugins (i.e. disable pluginadmin web panel) then only installed Trac components (as determined by system-admins ;) will be available in the admin GUI for trac-admins to choose from . I mean , plugin may be refactored to work this way. Specific hook extensions should be implemented by somebody anyway, but only system-admins will be able to install them in there ;) provided that trac-admin(s) don't have direct access to the system (e.g. via ssh ) . But hey, I'm not keen on trying to push through an obvious way for trac-admins to run code on the server by pointing out that there already is another, less obvious, way to do just that. Not when that other mechanism is so useful to me as a trac-admin. :) No what I'm envisioning is a plugin that works a lot like github's hook functions. On github a set of hook functions are available to the repo admin to choose from. yes it's similar to Bitbucket as well [3]_ . afaicr , in Bb you could even build your own hooks (a.k.a. brokers) somehow ... let me check where is it ? ... yep [4]_ needless to say I 3 Bb ;) . It's a pythonic-ly djang-ish thingy :) Which functions are available is controlled by the system-admin. A repo-admin then ticks the ones that she/he wants,
Re: [Trac] VCS hook control from Trac web admin?
On Wed, Jan 25, 2012 at 14:48, W. Martin Borgert deba...@debian.org wrote: Quoting Magnus Therning mag...@therning.org: They way I understand your plugin it would most likely not be acceptable in our environment. Having trac-admins write scripts that get executed on the server is not something the system-admin will allow. (This is in the name of security, and I know that there are other garage-door sized wholes already, like the ability for a trac-admin to upload any plugin. But hey, I'm not keen on trying to push through an obvious way for trac-admins to run code on the server by pointing out that there already is another, less obvious, way to do just that. Not when that other mechanism is so useful to me as a trac-admin. :) Just to be sure: Does your Trac run under uid 0 (root)? This would be completely unacceptable, of course. If Trac runs as its own, separated user, the shell scripts still can do harm, but e.g. not kill the system. Uploading plugins can be easily prohibited by setting the plugin dir to 555, very simple. Btw. plugins are only stored in the plugins dir and cannot access data, that the trac user (hopefully not root/0) is not allowed to access. *I* don't run the server, and I enjoy being able to upload plugins, so I will assume our system admins are competent enough to not run Apache/Trac/whatever as root, and I will *not* tell them how to prohibit uploading plugins. ;) /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] VCS hook control from Trac web admin?
Quoting Magnus Therning mag...@therning.org: I will *not* tell them how to prohibit uploading plugins. ;) Let's hope they don't read this mailing list :~) -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
[Trac] Email notification is sending only to CC
Any email notification is sending only to CC set in the trac.ini notification part. Also I have set use_public_cc to true Here is my [notifications] part [notification] admit_domains = always_notify_owner = false always_notify_reporter = false always_notify_updater = true ignore_domains = mime_encoding = base64 sendmail_path = smtp_always_bcc = smtp_always_cc = adam.interact@… smtp_default_domain = smtp_enabled = true smtp_from = trac.null@… smtp_from_name = Trac Null smtp_password = smtp_port = 587 smtp_replyto = trac.nullt@… smtp_server = smtp.gmail.com smtp_subject_prefix = default smtp_user = trac.null@… ticket_subject_template = $prefix #$ticket.id: $summary use_public_cc = true use_short_addr = false use_tls = true Notification email is sending only to CC, TO field is empty and I suspect to have there an email of a person for which a new ticket is assigned (as an example). -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
[Trac] Re: turning on trac post-commit script in trac v12.1, RHEL6
On Jan 25, 4:05 am, Cooke, Mark mark.co...@siemens.com wrote: I use windoze but I do have the ticketupdter working. It appears in admin as a component of the Trac 0.12.x plugin, not as a plugin in its own right. Expand the Trac item and search for `commit` on the page... Thanks for this tip, I've done this and can confirm the plugin is in fact installed and active. Also, did you disable the on-access synchronisation of repositories (using [trac] `repository_sync_per_request` option)? Erm, no... Odd... I've disabled it now, and have found a page I don't remember seeing before on the wiki by searching for that term, linking it here http://trac.edgewall.org/wiki/0.12/TracRepositoryAdmin Also, the functionality was not in 0.11 yet you say it worked, do you have a separate plugin that needs to be removed/disabled? Hmm... the post-commit-hook script functionality has been around for ages, since version 10 I believe. Was the main reason I chose Trac as an issue tracker, honestly. This plugin business is new, though. Thanks for your tips, am trying out turning off on-access synchronisation of repositories right now. Just have to gin up a reason to make a commit. Hope that helps... ~ mark c -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
[Trac] Re: turning on trac post-commit script in trac v12.1, RHEL6
Alas, turning off on-access synchronisation of repositories did not cause the post-commit hook script to work. I'm about to concede defeat. On Jan 25, 10:11 am, HardyPottinger hardy.pottin...@gmail.com wrote: On Jan 25, 4:05 am, Cooke, Mark mark.co...@siemens.com wrote: I use windoze but I do have the ticketupdter working. It appears in admin as a component of the Trac 0.12.x plugin, not as a plugin in its own right. Expand the Trac item and search for `commit` on the page... Thanks for this tip, I've done this and can confirm the plugin is in fact installed and active. Also, did you disable the on-access synchronisation of repositories (using [trac] `repository_sync_per_request` option)? Erm, no... Odd... I've disabled it now, and have found a page I don't remember seeing before on the wiki by searching for that term, linking it here http://trac.edgewall.org/wiki/0.12/TracRepositoryAdmin Also, the functionality was not in 0.11 yet you say it worked, do you have a separate plugin that needs to be removed/disabled? Hmm... the post-commit-hook script functionality has been around for ages, since version 10 I believe. Was the main reason I chose Trac as an issue tracker, honestly. This plugin business is new, though. Thanks for your tips, am trying out turning off on-access synchronisation of repositories right now. Just have to gin up a reason to make a commit. Hope that helps... ~ mark c -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
[Trac] Re: turning on trac post-commit script in trac v12.1, RHEL6
The svn-hook-myrepositoryname.log file indicates my test commits are being processed... so I'm beginning to think something might be amiss in the script itself somewhere. Everything I'm running came with Trac or was copy/pasted from the wiki, so I guess I'll just have to go over it all until I find something that looks wrong. In my searches today I also came across the alternative plugin called TracTicketChangesetsPlugin, so, if all else fails, I'll try setting that up instead. Though, right now, I'm looking to see if perhaps I just need to modify the suggested config values for the plugin, so the commands we're used to typing will still work. I've tried setting the envelope to blank, and expressly setting the close and update commands, but so far, no luck. I'm debugging by calling the post-commit script directly, as the wiki suggests, as the apache user, which is much more convenient than making fake commits. On Jan 25, 10:28 am, HardyPottinger hardy.pottin...@gmail.com wrote: Alas, turning off on-access synchronisation of repositories did not cause the post-commit hook script to work. I'm about to concede defeat. On Jan 25, 10:11 am, HardyPottinger hardy.pottin...@gmail.com wrote: On Jan 25, 4:05 am, Cooke, Mark mark.co...@siemens.com wrote: I use windoze but I do have the ticketupdter working. It appears in admin as a component of the Trac 0.12.x plugin, not as a plugin in its own right. Expand the Trac item and search for `commit` on the page... Thanks for this tip, I've done this and can confirm the plugin is in fact installed and active. Also, did you disable the on-access synchronisation of repositories (using [trac] `repository_sync_per_request` option)? Erm, no... Odd... I've disabled it now, and have found a page I don't remember seeing before on the wiki by searching for that term, linking it here http://trac.edgewall.org/wiki/0.12/TracRepositoryAdmin Also, the functionality was not in 0.11 yet you say it worked, do you have a separate plugin that needs to be removed/disabled? Hmm... the post-commit-hook script functionality has been around for ages, since version 10 I believe. Was the main reason I chose Trac as an issue tracker, honestly. This plugin business is new, though. Thanks for your tips, am trying out turning off on-access synchronisation of repositories right now. Just have to gin up a reason to make a commit. Hope that helps... ~ mark c -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] VCS hook control from Trac web admin?
On Wed, Jan 25, 2012 at 09:20:11AM -0500, Olemis Lang wrote: On Wed, Jan 25, 2012 at 7:23 AM, Magnus Therning mag...@therning.org wrote: common case ;) you should have more control over this once multi-project support will be ready ... but it's not yet Would an option be to make it per-repository rather than per-project? I guess the config would be slightly more complicated, but at the same time it might be easier to grasp what's going on as well as slightly more configurable. They way I understand your plugin it would most likely not be acceptable in our environment. Having trac-admins write scripts that get executed on the server is not something the system-admin will allow. that's exactly the goal of the plugin , to implement components inside a Trac environment so as to allow for hook customization but without full access to VCS-specific hook machinery ;) Then maybe I'm just confused by the screen-shot, it gives the impression that it's possible to write bash code to be executed on the hook. Which functions are available is controlled by the system-admin. A repo-admin then ticks the ones that she/he wants, with some configuration possible, like if a mail is to be sent on commit, where does it get sent, etc. **similar** to what is displayed in this screenshot [1]_ but without the possibility to edit hook script directly (i.e. only what u see below Listeners on this hook section) ? Ah, I did miss that little detail earlier. Good that you pointed it out. Indeed, it's only that last bit I'd be interested in. I can see a use for making hooks fully editable through the web admin, but it'd be nice if a system-admin could turn it off somehow. This means the system-admin has full control of what code can possibly get run on the server, while the repo-admin can choose the functions that make sense for each repo. Adding a new function is a bit bureaucratic, but does allow the system-admin to stay in charge. ... if we put all the pieces mentioned above together then it should be possible to achieve what u want ... isn't it ? Yes, I'm starting to agree with you :) /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay pgpDmOuikRYDa.pgp Description: PGP signature
