Prospects: MS Exchange + Linux

    I want to talk about the future happiness for Linuxoids, in terms of supporting the native MS Exchange MAPI protocol, as well as what has already been implemented and what you can play with now.

    Many who tried to configure access to MS Exchange from Linux probably always in their search came to only one solution - Evolution + exchange plugin for it. More curious. They know HOW and with what mother this support is realized. And it always becomes sad, because Exchange is in many places, for example in the state. authorities and provides collaboration of people and Linux without the support of the Exchange access protocol, unfortunately, the road is closed there. So it was before, but now ...



    There is a very good project called openchange (http://openchange.org/). According to the developers, this is an Open Source implementation of the MAPI protocol (http://ru.wikipedia.org/wiki/MAPI). As Wikipedia says: MAPI is the interface of a program that works with e-mail in Microsoft Windows. MAPI allows you to receive, read, create, send email messages, attach files to them (or access attached files), etc. In addition, the protocol also provides features such as shared calendars. contacts, shared directories, tasks, and notes. In general, everything you need to work together.

    Until recently, for the most part, only Windows and MS Outlook users could use all this wealth. But at the moment, Linux users have firstly the library itself implementing the mapi protocol (libmapi www.openchange.org/index.php?option=com_content&task=view&id=63&Itemid=71), already available in many distributions, and secondly, the wonderful KDE4, with its Akonadi. In addition, Akonadi already has a resource that is an interface between Akonadi and the libmapi library, already located in kdepim (http://www.openchange.org/index.php?option=com_content&task=view&id=111&Itemid=87). There is only one snag - so far this resource is more a technological project than something completed and as a result, is not yet available to users. But what to do if it really hurts? As for me, if there is an urgent production need =)

    Below is a small guide on the topic "How to get to MS Exchange from under KDE4" =). And if the assembly is not interested, you can immediately scroll through the next few paragraphs and look at the result.

    Firstly, we will decide what we have. For example, we have, as in my case, the Debian Lenny distribution, the KDE 4.2 windowing environment and libmapi 0.8 in the experimental repository. What can we do about it? To begin with, we will need to download the libmapi sources, change them a bit, compile packages from them and install them on the system. To make it immediately clear why this is necessary, I will say that kdepim uses a C ++ wrapper over libmapi (as a set of headers) called libmapi ++. In turn, the original sources of the library contain these headers, but the package builders, apparently deciding that while no one needs these headers, collect the libmapi ++ - dev package. Well, do it yourself.

    Create a directory in our home directory, for example ~ / kdepim / libmapi /:
    $ mkdir -p ~ / kdepim / libmapi /
    $ cd ~ / kdepim / libmapi /

    Now, add the debian source package repositories to our sources.list and run sudo apt-get update. This will not be described for obvious reasons =) After that, in the ~ / kdepim / libmapi / directory, execute the command
    $ apt-get source libmapi0

    After which we will get three files and a directory with the unpacked sources and the patch applied to them. Let's go to the directory that appears, run dpkg-checkbuilddeps in it and install all the packages which are not enough to build, plus the libboost-dev package. Attention: among other things, this package for assembly also requires the samba4-dev package, which in turn pulls samba4 itself and there is a chance that samba will simply stop working in the system.

    Next, open the debian / rules file and comment out the line “rm -rf $ (CURDIR) / debian / tmp / usr / include / libmapi ++”, and vice versa, add a few new ones in the debian / control file:
    Package: libmapi ++ - dev
    Section: libdevel
    Architecture: any
    Depends: libc6-dev, libmapi0 (= $ {binary: Version}), $ {misc: Depends}
    Description: Development files for the MAPI client library
    This library provides a client-side implementation of the MAPI protocol
    that is used by Microsoft Exchange and Outlook.
    .
    Currently implemented features include sending and receiving mail and
    enumerating the address book.
    .
    This package contains the development files.

    All that remains is to assemble the library into packages using the dpkg-buildpackage -rfakeroot command. True, in my case there were several problems. Firstly, in samba, suddenly in some structures the private field was changed to private_data, and so I had to shamanize a little more with the sources, and secondly, the samba headers are not where they should be, according to the same headers of other libraries. that is, not in / usr / include, but hidden in /usr/include/samba-4.0, which creates some problems during compilation, when the header cannot be found, by no means =). By the way, all this is done only to build a new package libmapi ++ - dev containing a set of headers. So if you are too lazy to compile this whole thing yourself, then the finished package can be picked up here: narod.ru/disk/8149428000/libmapi%2B%2B-dev_0.8-2_i386.deb.html. After downloading, install the package into the system and proceed to the next step - patching and building kdepim.

    Create another directory. for example ~ / kdepim / kdepimOCresource / and go into it. We execute apt-get source kdepim and get at our disposal the sources of all kdepim with patches from Debian. go to the source directory. install assembly dependencies. Then we go into the akonadi / resources directory and change the CMakeLists.txt file by typing the line “add_subdirectory (openchange)” after the line “add_subdirectory (distlist)", this is somewhere in the 28th line of the file. Now open the debian / akonadi-kde.install file and append the lines to it:
    usr / bin / akonadi_oc_resource
    usr / share / akonadi / agents / ocresource.desktop

    In the file akonadi / resources / openchange / CMakeLists.txt in the line “set (CMAKE_CXX_FLAGS„ $ {CMAKE_CXX_FLAGS} -I% {LIBMAPI_INCLUDE_DIRS} $ {KDE4_ENABLE_EXCEPTIONS} “)" add "-lmapi

    Finally, to make everything human, add a new dependency for the akonadi-kde package to the control file. Her name, of course, is libmapi0. This is where the source change is complete, we start the assembly of binary packages and wait for its successful (I hope) end. When everything is completed, you will need to reinstall the akonadi-kde reassembled package into the system, after which a new OpenChange will appear in the list of its resources. To avoid rebuilding this package can also be downloaded, here: narod.ru/disk/8149908000/akonadi-kde_4.2.2-1_i386.deb.html. The final touch - in the user directory you need to create the ".openchange" directory, otherwise the resource will fall all the time =)

    - end of assembly guide =)

    After all these ordeals, by going to "System Settings -> Akonadi Settings" and clicking on the "Add" button on the "Configuring Akonadi Sources" tab, OpenChange will appear in the list of proposed resources, that is, exactly what we need =). We select it, double-click on it, create a new profile and make this the default profile. After that, it remains to run akonadiconsole through the console, go to the “Resources” tab, click “Synchronize -> Synchronize All” and go to the Browser tab, where it is already visible that the folders are synchronized, everything works and is displayed ... True, without the Cyrillic alphabet, you really all of this can fall at any moment. but none the less. some progress is already visible and I want to hope that by the release of kde 4.3 most of the errors will still be fixed and the resource will go into distribution builds, one distresses,

    What else can be done? So far, almost nothing, except maybe, just try to start Kontact, which must certainly fall when trying to add a new Akonadi calendar =) In general, the developers’s idea is excellent, the implementation at this stage is also not bad, although it is lame =) A lot of additional information can be also find the links in the article, and especially on the resource www.openchange.org

    Also popular now: