Howto create private channel on Freenode

March 25, 2014 in configuration, fedora, howto, IRC

As it happens I sometimes need to create a private IRC channel for prolonged time where nobody but selected people should be able to join. This is a step by step guide to do it on Freenode:

Prerequisities:

  • All participants have registered usernames
  • You must be channel operator (OP) and the channel must NOT be registered (otherwise contact one of channel founders or pick different channel)

Step by step process

  1. /msg chanserv register <channel>
  2. /msg chanserv set <channel> guard on (Chanserv will join your channel)
  3. /mode <channel> +i (set channel to invite only)
  4. /msg chanserv access <channel> add <nick> (for each person that should be able to join)
  5. /mode <channel> +I <nick> (for each person that should be able to join)
  6. Prosper!

Other people modifications

Add person as co-founder (full permissions):

  • /msg chanserv access <channel> add <nick> FOUNDER

Automatically give OP status to person after joining:

  • /msg chanserv flags <channel> <nick> +O

Allow people to invite others:

  • /msg chanserv flags <channel> <nick> +i

For full information try /msg chanserv help, /msg chanserv help flags and /help mode.

fedwatch – running scripts based on fedmsg messages

March 21, 2014 in automation, fedmsg, fedora, projects

Fedora fedmsg infrastructure can give you a lot of interesting information nearly in real-time. For example:

  • Koji build starts/finishes/fails
  • FAS account creation and membership changes
  • Changes in Fedora packages git repositories
  • Changes of package ownership in pkgdb
  • Changes to bodhi updates

Full list of topics is of course online, including the data in those messages.

It doesn’t take a genius to realize some of these messages can be used to do interesting stuff. For example Java SIG uses buildsys.repo.done to generate minimal installation size of several packages each time rawhide buildroot is regenerated. That way we immediately see if some new dependency creeps in.

To make all of this more simple I created a separate library and utility for monitoring specified topics on fedmsg bus and then running scripts in configured directory with data from fedmsg message passed as arguments. Introducing: fedwatch.

Installation

I am planning to package fedwatch for Fedora and EPEL. In the meantime feel free to use my Copr repo.

If you have up-to-date dnf-plugins-core you can just do dnf copr enable sochotni/fedwatch fedora-<ver>-<arch>

If you are not using dnf you can download appropriate repository for your distribution manually (F20, rawhide, EPEL 6 supported) and then just run yum install fedwatch .

Usage

# fedwatch --help
usage: fedwatch [-h] [--config-file CONFIG_FILE] [--script-dir SCRIPT_DIR]
                [--debug]

Run tasks on fedmsg changes

optional arguments:
  -h, --help            show this help message and exit
  --config-file CONFIG_FILE
                        Configuration file for topic selection and data
                        mapping (default: /etc/fedwatch.conf)
  --script-dir SCRIPT_DIR
                        Directory with scripts to run for fedmsg messages
                        (default: /etc/fedwatch.d)
  --debug               Run with debug output (default: False)

Configuration file format is that of standard ini file (ConfigParser format for Pythonistas). Example:

[org.fedoraproject.prod.git.receive]
arg1=msg/commit/username
arg2=msg/commit/repo
arg3=msg/commit/branch
arg4=msg/commit/rev
arg5=msg/commit/summary

When fedwatch receives a git.receive message it will convert fedmsg message data into arguments for running scripts based on above configuration. Keys in the configuration file are ignored and values are evaluated as XPath expressions inside the message data. So msg/commit/username means message[‘msg’][‘commit’][‘username’].

Taking an example fedmsg commit message from fedmsg documentation:

{ 'i': 1,
  'msg': { 'commit': { 'branch': 'master',
                       'email': 'mjw@redhat.com',
                       'message': 'Clear CFLAGS CXXFLAGS LDFLAGS.\n\n-This is a bit of a hammer.',
                       'name': 'Mark Wielaard',
                       'repo': 'valgrind',
                       'rev': '7a98f80d9b61ce167e4ef8129c81ed9284ecf4e1',
                       'stats': { 'files': { 'valgrind.spec': { 'deletions': 2,
                                                                'insertions': 1,
                                                                'lines': 3}},
                                  'total': { 'deletions': 2,
                                             'files': 1,
                                             'insertions': 1,
                                             'lines': 3}},
                       'summary': 'Clear CFLAGS CXXFLAGS LDFLAGS.',
                       'username': 'mjw'}},
  'timestamp': 1344350850.886738,
  'topic': 'org.fedoraproject.prod.git.receive'}

For the above configuration file and this specific message, fedwatch would execute scripts in /etc/fedwatch.d/ with following arguments:

<script> org.fedoraproject.prod.git.receive mjw valgrind master \
       7a98f80d9b61ce167e4ef8129c81ed9284ecf4e1 'Clear CFLAGS CXXFLAGS LDFLAGS.'

And example script to handle the above message could be /etc/fedwatch.d/10-git-receive.sh:

#!/bin/sh

if [[ "$1" != "org.fedoraproject.prod.git.receive" ]];then
    exit 0
fi

username=$1
pkgname=$3
branch=$2

# do stuff

I hope the configuration file is easy to understand. Package contains systemd and SysV init integration so you can run it as a system-wide service. In that case I suggest you change default (empty) configuration in /etc/fedwatch.conf and add some handling scripts into /etc/fedwatch.d/.

And of course if you find some interesting use cases for fedwatch, let me know!