paul@988 | 1 | = Using imip-agent = |
paul@988 | 2 | |
paul@988 | 3 | With imip-agent deployed, usage of the software should occur automatically. |
paul@988 | 4 | However, evidence of its operation will only emerge when calendar-related |
paul@988 | 5 | messages are exchanged between e-mail users. This will cause a few different |
paul@988 | 6 | things to happen: |
paul@988 | 7 | |
paul@988 | 8 | * Summary messages may be sent by the calendar system to mail recipients |
paul@988 | 9 | |
paul@988 | 10 | * Replies to calendar-related messages may be received by the senders of |
paul@988 | 11 | those messages |
paul@988 | 12 | |
paul@988 | 13 | * Free/busy information will become available, either in responses to |
paul@988 | 14 | requests sent over e-mail, or [[../FreeBusyPublishing|over the Web]] |
paul@988 | 15 | |
paul@988 | 16 | In the background, imip-agent uses and updates information as described in the |
paul@988 | 17 | [[../FilesystemUsage|filesystem usage guide]]. |
paul@989 | 18 | |
paul@989 | 19 | == Creating User Data Stores == |
paul@989 | 20 | |
paul@989 | 21 | The [[../MailIntegration|mail system]] mechanisms are responsible for |
paul@989 | 22 | determining whether a valid recipient has been specified in any given message, |
paul@989 | 23 | and imip-agent does not attempt to validate such information again. Therefore, |
paul@989 | 24 | when a message is received for a calendar user for whom no data store has been |
paul@989 | 25 | initialised in the [[../FilesystemUsage|filesystem]], the software will |
paul@989 | 26 | automatically create one. |
paul@989 | 27 | |
paul@989 | 28 | Consequently, users for whom such data stores have been created will experience |
paul@989 | 29 | the software using the default configuration, described in the |
paul@989 | 30 | [[../Preferences|preferences guide]]. It is for this reason that the default |
paul@989 | 31 | values in the [[../Configuration|configuration]] should be adjusted according |
paul@989 | 32 | to the policies decided for the deployment of this software. |
paul@989 | 33 | |
paul@989 | 34 | However, it is possible to create data stores for users in advance using the |
paul@989 | 35 | `tools/init_user.sh` script as in the following example: |
paul@989 | 36 | |
paul@989 | 37 | {{{ |
paul@989 | 38 | tools/init_user.sh mailto:vincent.vole@example.com |
paul@989 | 39 | }}} |
paul@989 | 40 | |
paul@989 | 41 | Here, the user identity is given as a URI since this is how iCalendar references |
paul@989 | 42 | participants in scheduling operations. The result of the above command should be |
paul@989 | 43 | some new directories in the [[../FilesystemUsage|filesystem area]] dedicated to |
paul@989 | 44 | calendar information storage. |
paul@989 | 45 | |
paul@989 | 46 | === Adjusting Preferences === |
paul@989 | 47 | |
paul@989 | 48 | Once initialised, the user preferences can be adjusted by adding files to the |
paul@989 | 49 | `preferences` directory created by the above command. For example, if a user has |
paul@989 | 50 | elected to not participate in the calendar system, a file called `participating` |
paul@989 | 51 | can be added as follows: |
paul@989 | 52 | |
paul@989 | 53 | {{{ |
paul@989 | 54 | echo 'no' > '/var/lib/imip-agent/preferences/mailto:vincent.vole@example.com/participating' |
paul@989 | 55 | }}} |
paul@989 | 56 | |
paul@989 | 57 | Here, the default storage location has been given in the filename. |
paul@989 | 58 | |
paul@989 | 59 | Normally, users should visit the [[../CalendarManager|management interface]] to |
paul@989 | 60 | change their preferences, but modifications done by administrators are more |
paul@989 | 61 | efficiently performed by directly interacting with the filesystem. For example, |
paul@989 | 62 | an administrator might initialise the common names of users by scripting changes |
paul@989 | 63 | to the `CN` file for each user, obtaining such names from some kind of database. |
paul@989 | 64 | |
paul@989 | 65 | == Excluding Users Entirely == |
paul@989 | 66 | |
paul@989 | 67 | Since the [[../AgentPrograms|agent programs]] are installed as part of the mail |
paul@989 | 68 | handling workflow, even the configuration of non-participation in the calendar |
paul@989 | 69 | system for users will still result in those users' messages being passed along |
paul@989 | 70 | the workflow by imip-agent, which may result in a decrease in general mail |
paul@989 | 71 | delivery performance. |
paul@989 | 72 | |
paul@989 | 73 | To exclude users entirely, the routing configuration of the |
paul@989 | 74 | [[../MailIntegration|MTA]] needs to be changed so that such users identities are |
paul@989 | 75 | not recognised as calendar system participants, thus preventing their messages |
paul@989 | 76 | from being routed via imip-agent. This is as simple as either not listing the |
paul@989 | 77 | identity in [[../MailIntegration/Simple|lists of addresses]] or by adjusting |
paul@989 | 78 | [[../MailIntegration/LDAP|queries yielding calendar users]]. |