paul@994 | 1 | = Administering 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@994 | 46 | === Initialising Resources === |
paul@994 | 47 | |
paul@994 | 48 | Resources belong to a class of user whose preferences should be configured in |
paul@994 | 49 | advance because their policies may differ on a case-by-case basis. For example, |
paul@994 | 50 | some resources may benefit from employing the `permitted_times` setting so that |
paul@994 | 51 | a granularity on event times may be imposed, meaning that such resources would |
paul@994 | 52 | be "handed over" at regular intervals. |
paul@994 | 53 | |
paul@994 | 54 | The `freebusy_offers` setting, together with the `scheduling_function` setting, |
paul@994 | 55 | would allow different kinds of resources to "keep open" tentatively-suggested |
paul@994 | 56 | periods for different lengths of time, allowing frequently-requested resources |
paul@994 | 57 | to respond to scheduling requests in a timely fashion, whilst also allowing |
paul@994 | 58 | other resources to give more time to event organisers to respond to their |
paul@994 | 59 | counter-proposals. |
paul@994 | 60 | |
paul@989 | 61 | === Adjusting Preferences === |
paul@989 | 62 | |
paul@989 | 63 | Once initialised, the user preferences can be adjusted by adding files to the |
paul@989 | 64 | `preferences` directory created by the above command. For example, if a user has |
paul@989 | 65 | elected to not participate in the calendar system, a file called `participating` |
paul@989 | 66 | can be added as follows: |
paul@989 | 67 | |
paul@989 | 68 | {{{ |
paul@989 | 69 | echo 'no' > '/var/lib/imip-agent/preferences/mailto:vincent.vole@example.com/participating' |
paul@989 | 70 | }}} |
paul@989 | 71 | |
paul@989 | 72 | Here, the default storage location has been given in the filename. |
paul@989 | 73 | |
paul@989 | 74 | Normally, users should visit the [[../CalendarManager|management interface]] to |
paul@989 | 75 | change their preferences, but modifications done by administrators are more |
paul@989 | 76 | efficiently performed by directly interacting with the filesystem. For example, |
paul@989 | 77 | an administrator might initialise the common names of users by scripting changes |
paul@989 | 78 | to the `CN` file for each user, obtaining such names from some kind of database. |
paul@989 | 79 | |
paul@989 | 80 | == Excluding Users Entirely == |
paul@989 | 81 | |
paul@989 | 82 | Since the [[../AgentPrograms|agent programs]] are installed as part of the mail |
paul@989 | 83 | handling workflow, even the configuration of non-participation in the calendar |
paul@989 | 84 | system for users will still result in those users' messages being passed along |
paul@989 | 85 | the workflow by imip-agent, which may result in a decrease in general mail |
paul@989 | 86 | delivery performance. |
paul@989 | 87 | |
paul@989 | 88 | To exclude users entirely, the routing configuration of the |
paul@989 | 89 | [[../MailIntegration|MTA]] needs to be changed so that such users identities are |
paul@989 | 90 | not recognised as calendar system participants, thus preventing their messages |
paul@989 | 91 | from being routed via imip-agent. This is as simple as either not listing the |
paul@989 | 92 | identity in [[../MailIntegration/Simple|lists of addresses]] or by adjusting |
paul@989 | 93 | [[../MailIntegration/LDAP|queries yielding calendar users]]. |