Outlook: MS Exchange + Linux
I want to talk about the future happiness for Linux users, in terms of supporting the native MS Exchange MAPI protocol, as well as what has already been implemented and with which you can already play.
Many who tried to configure access to MS Exchange from Linux were probably always in their search for only one solution - Evolution + exchange plugin for it. More curious. they know HOW and with the help of which mother this support is realized. And it always becomes sad, because Exchange is in many places, for example in the state. bodies and ensures the joint work 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, the name of which is openchange (http://openchange.org/). According to the developers, this is the Open Source implementation of the MAPI protocol (http://ru.wikipedia.org/wiki/MAPI). As Wikipedia says: MAPI is a program interface that works with e-mail in Microsoft Windows. MAPI allows you to receive, read, create, send e-mail 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 the first library that implements the mapi protocol itself (libmapi www.openchange.org/index.php?option=com_content&task=view&id=63&Itemid=71 ), which is already available in many distributions, and secondly - a great KDE4, with its Akonadi. In addition, Akonadi already has a resource, which is the interface between Akonadi and the libmapi library, already in kdepim (http://www.openchange.org/index.php?option=com_content&task = view&id=111&Itemid=87). There is only one catch - 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 pushes? As for me, for example, in the event of an acute production need =)
Below is a small tutorial on "How to reach MS Exchange from under KDE4" =). And if the assembly is not interested, you can immediately scroll through several of the following paragraphs and look at the result.
First, let's define what we have. We have, for example, as in my case, the Debian Lenny distribution, the KDE 4.2 window environment and libmapi 0.8 in the experimental repository. What can we do about it? To begin with, we will need to download the source code of libmapi, change them a bit, build packages from them and install them in the system. To make it immediately clear why this is needed, I will say that kdepim uses C ++ wrapper over libmapi (as a set of headers), called libmapi ++. In turn, the original sources of the library have these headers, but package builders, apparently deciding that for the time being, no one needs these headers to build 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 to our sources.list package source repository for debian and run sudo apt-get update. For obvious reasons, this will not be described =) After that, being in the ~ / kdepim / libmapi / directory we execute the command
$ apt-get source libmapi0
After that, we get three files and a directory with unpacked sources and a patch superimposed on them. Go to the directory that appears, run dpkg-checkbuilddeps in it and install all the packages that are not enough to build, plus the libboost-dev package. Attention: among other things, this package also requires the samba4-dev package, which in turn draws samba4 itself, and there is a possibility that the samba will simply stop working in the system.
Next, we open the debian / rules file and comment on the line “rm -rf $ (CURDIR) / debian / tmp / usr / include / libmapi ++”, and in the debian / control file, on the contrary, add a few new ones:
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 MAPI protocol
that is used by Microsoft Exchange and Outlook.
.
Received Received Mail
enumerating the address book.
.
This package contains the development files.
It remains only to assemble the library into packages using the dpkg-buildpackage -rfakeroot command. True, in my case, there were several problems. Firstly, in a samba, in some structures, the private field was suddenly changed to private_data and, therefore, we had to shamanize a bit more with the source code, and secondly, the samba headers are not where they are supposed to lie 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 when compiling, when the title cannot be found by any means =). By the way, all this is done only to build a new libmapi ++ - dev package containing a set of headers. So if you are too lazy to compile the whole thing yourself, then you can pick up the finished package 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 assembling kdepim.
Create another directory. for example ~ / kdepim / kdepimOCresource / and move to it. We execute apt-get source kdepim and get at our disposal the source code of all kdepim with patches from debian. go to the source directory. we install assembly dependences. Then we go to the akonadi / resources directory and change the CMakeLists.txt file by typing in the line “add_subdirectory (openchange)” after the line “add_subdirectory (distlist)”, this is about 28 lines of the file. Now open the debian / akonadi-kde.install file and add 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, for everything to be human, let's 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 build of binary packages and wait for its successful (hopefully) ending. When everything is complete, you will need to install the akonadi-kde reassembled package into the system, after which a new one will appear in the list of its resources - OpenChange. To do without rebuilding this package can also be downloaded here: narod.ru/disk/8149908000/akonadi-kde_4.2.2-1_i386.deb.html . The final touch is to create the directory ".openchange" in the user directory, otherwise the resource will always fall =)
- end of assembly manual =)
After all these ordeals, go to "System Settings -> Configure Akonadi" and click on the "Add" button on the "Configure Akonadi sources" tab, OpenChange appears in the list of suggested resources, that is, exactly what we need =). Select it, double click on it, create a new profile and make this profile the default. After that, it will remain to run akonadiconsole via the console, go to the “Resources” tab, click “Synchronize -> Synchronize All” and go to the Browser tab, where you can already see that the folders are synchronized, everything works and is displayed ... But for now, without Cyrillic all this can fall at any time. but none the less. some progress is already visible and I would like to hope that by the release of kde 4.3 most of the errors will be corrected and the resource will be included in the distributive assemblies, one disturbs, the commits in its source files were quite long ... KDE / kdepim / akonadi / resources / openchange /)
What else can you do? So far, almost nothing, except maybe, try to start Kontact, which should certainly fall when trying to add a new Akonadi calendar =) In general, the developers have an excellent idea, the implementation at this stage is also not bad, although it is lame =) A lot of additional information can be find also on the links in the article, and especially on the resource www.openchange.org
Many who tried to configure access to MS Exchange from Linux were probably always in their search for only one solution - Evolution + exchange plugin for it. More curious. they know HOW and with the help of which mother this support is realized. And it always becomes sad, because Exchange is in many places, for example in the state. bodies and ensures the joint work 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, the name of which is openchange (http://openchange.org/). According to the developers, this is the Open Source implementation of the MAPI protocol (http://ru.wikipedia.org/wiki/MAPI). As Wikipedia says: MAPI is a program interface that works with e-mail in Microsoft Windows. MAPI allows you to receive, read, create, send e-mail 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 the first library that implements the mapi protocol itself (libmapi www.openchange.org/index.php?option=com_content&task=view&id=63&Itemid=71 ), which is already available in many distributions, and secondly - a great KDE4, with its Akonadi. In addition, Akonadi already has a resource, which is the interface between Akonadi and the libmapi library, already in kdepim (http://www.openchange.org/index.php?option=com_content&task = view&id=111&Itemid=87). There is only one catch - 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 pushes? As for me, for example, in the event of an acute production need =)
Below is a small tutorial on "How to reach MS Exchange from under KDE4" =). And if the assembly is not interested, you can immediately scroll through several of the following paragraphs and look at the result.
First, let's define what we have. We have, for example, as in my case, the Debian Lenny distribution, the KDE 4.2 window environment and libmapi 0.8 in the experimental repository. What can we do about it? To begin with, we will need to download the source code of libmapi, change them a bit, build packages from them and install them in the system. To make it immediately clear why this is needed, I will say that kdepim uses C ++ wrapper over libmapi (as a set of headers), called libmapi ++. In turn, the original sources of the library have these headers, but package builders, apparently deciding that for the time being, no one needs these headers to build 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 to our sources.list package source repository for debian and run sudo apt-get update. For obvious reasons, this will not be described =) After that, being in the ~ / kdepim / libmapi / directory we execute the command
$ apt-get source libmapi0
After that, we get three files and a directory with unpacked sources and a patch superimposed on them. Go to the directory that appears, run dpkg-checkbuilddeps in it and install all the packages that are not enough to build, plus the libboost-dev package. Attention: among other things, this package also requires the samba4-dev package, which in turn draws samba4 itself, and there is a possibility that the samba will simply stop working in the system.
Next, we open the debian / rules file and comment on the line “rm -rf $ (CURDIR) / debian / tmp / usr / include / libmapi ++”, and in the debian / control file, on the contrary, add a few new ones:
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 MAPI protocol
that is used by Microsoft Exchange and Outlook.
.
Received Received Mail
enumerating the address book.
.
This package contains the development files.
It remains only to assemble the library into packages using the dpkg-buildpackage -rfakeroot command. True, in my case, there were several problems. Firstly, in a samba, in some structures, the private field was suddenly changed to private_data and, therefore, we had to shamanize a bit more with the source code, and secondly, the samba headers are not where they are supposed to lie 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 when compiling, when the title cannot be found by any means =). By the way, all this is done only to build a new libmapi ++ - dev package containing a set of headers. So if you are too lazy to compile the whole thing yourself, then you can pick up the finished package 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 assembling kdepim.
Create another directory. for example ~ / kdepim / kdepimOCresource / and move to it. We execute apt-get source kdepim and get at our disposal the source code of all kdepim with patches from debian. go to the source directory. we install assembly dependences. Then we go to the akonadi / resources directory and change the CMakeLists.txt file by typing in the line “add_subdirectory (openchange)” after the line “add_subdirectory (distlist)”, this is about 28 lines of the file. Now open the debian / akonadi-kde.install file and add 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, for everything to be human, let's 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 build of binary packages and wait for its successful (hopefully) ending. When everything is complete, you will need to install the akonadi-kde reassembled package into the system, after which a new one will appear in the list of its resources - OpenChange. To do without rebuilding this package can also be downloaded here: narod.ru/disk/8149908000/akonadi-kde_4.2.2-1_i386.deb.html . The final touch is to create the directory ".openchange" in the user directory, otherwise the resource will always fall =)
- end of assembly manual =)
After all these ordeals, go to "System Settings -> Configure Akonadi" and click on the "Add" button on the "Configure Akonadi sources" tab, OpenChange appears in the list of suggested resources, that is, exactly what we need =). Select it, double click on it, create a new profile and make this profile the default. After that, it will remain to run akonadiconsole via the console, go to the “Resources” tab, click “Synchronize -> Synchronize All” and go to the Browser tab, where you can already see that the folders are synchronized, everything works and is displayed ... But for now, without Cyrillic all this can fall at any time. but none the less. some progress is already visible and I would like to hope that by the release of kde 4.3 most of the errors will be corrected and the resource will be included in the distributive assemblies, one disturbs, the commits in its source files were quite long ... KDE / kdepim / akonadi / resources / openchange /)
What else can you do? So far, almost nothing, except maybe, try to start Kontact, which should certainly fall when trying to add a new Akonadi calendar =) In general, the developers have an excellent idea, the implementation at this stage is also not bad, although it is lame =) A lot of additional information can be find also on the links in the article, and especially on the resource www.openchange.org
Source: https://habr.com/ru/post/58455/
All Articles