Using Evolution with Exchange Server

Evolution is to Outlook, as Thunderbird is to Outlook Express. While Thunderbird will let you get your email from your ISP, and from Google (and sometimes, when it fecking works, hotmail), Evolution's big selling point is that it works with Exchange. Exchange being Microsoft's email server.

To get Evolution working in either Ubuntu or Arch you need to install the following packages:

evolution evolution-exchange

When you have installed these, you configure Evolution as follows:
Add an account and specify type as Exchange Server.
You then set these variables:
Receiving E-mail → Username = [domain]/[logon_name]
Receiving E-mail → OWA URL is https://[mail_server_name]/exchange
Receiving Options → Global Catalogue Server Name = [mail_server_ip_address]
Default → Sent Messages Folder = set to Exchange not Local
The system should auto find the exchange account if you click authenticate.
Public Folders are accessed by going Folder → Subscriptions, and choosing Exchange Server.
[domain] examples would be, smoobandit.com, smoobanditprivate.local

Once you pop in your password you should find that Evolution connects and starts downloading all your mail.

However, this is buggier than a trap for Indiana Jones. Every so often, including more than once per day, it will fubar its connection to the exchange server. It either denies there is any mail, or tells you you have 3 messages in the last 3 months. Sometimes this is accompanied by an error saying that it has lost connection to the backend something or other. Sometimes not. The only way to fix this, that I have found, is to open a terminal and run these commands:

evolution --force-shutdown
cd ~/.evolution/mail/exchange
sudo rm -rfv ./[domain]

Then re-run Evolution and it will re-sync to Exchange. This is OK, unless you have something stored locally and not on the server. For instance, if you were drafting an email when the connection fubarred, then you would lose that because it would only be stored locally. Bastard.

Linux Documentation

I have complained before about the really crappy documentation that you encounter when trying to trawl through linux manuals. Two recent examples may shed some light on the nature of my complaint.

Firstly, in my last post I talked about the xdg-mime command and how it is used to change the default application for various filetypes. What I did not say was how frustrating the documentation was to deal with. For instance, go and look at the manual page for xdg-mime. It all starts well enough:

xdg-mime — command line tool for querying information about file type handling and adding descriptions for new file types

That's a nice intro, and sets the scene well. We know what we are talking about. Also, the description gives us some more useful information:

The xdg-mime program can be used to query information about file types and to add descriptions for new file types.

Good. Good. Keep it coming. Lets have a look at the synopsis of the command:

xdg-mime query { filetype | default }

Right, so we type "xdg-mime query" and then what? Oh - filetype. Right, so I am interested in PDFs. Lets try:

xdg-mime query pdf

Aaaaaaand:

xdg-mime: unknown query type 'pdf'

Fucking great. The system must know about PDFs because it is opening them now (with GIMP, which is fucking annoying and the whole point of this little command line adventure). What could I be doing wrong?

Slowly the light dawns. When it says 'filetype' that is not a variable, that is literally what you type. So you follow 'xdg-mime query' with the word 'filetype'. Right, brilliant. So why the fuck could the error report not say:

xdg-mime: unknown query type 'pdf'.  Valid querys are 'filetype' and 'default'.

It's not that hard to type out six words.

OK, so we follow 'xdg-mime query' with either "filetype" or "default". I can follow that. Fine. So what do I type after filetype or default? Lets see...

query filetype FILE: Returns the file type of FILE in the form of a MIME type.

Right, so I now try:

xdg-mime query filetype forfuckssake.pdf:

Aaaaaand:

xdg-mime: file 'forfuckssake.pdf:' does not exist

Yes it fucking does I am looking at it! So I check the spelling, and the path. I try "./" before the filename, because god knows linux gets picky about finding stuff not in the path - even when you are in the same fecking directory as the file you want to use! Nada.

Then a further little light dawns. See the colon at the end of the filename? What if maybe, just maybe, that shouldn't be fucking there? What if the instructions, which specifically appended a colon to the end of the filename, and which I am following carefully, not just being slap happy with my colons in general, were put together with all the skill and panache of a recovering alcoholic with the DTs trying to construct a house of cards? Leave off the colon = command works as it should. Genius.

Secondly, I have been farting around with the larch system for making live usb installations of Arch. One of which I am using to post this, as a matter of fact. To cut a long story short, I wanted to add some extra packages to the install which were not in the repositories. The Larch manual states:

It is possible to include your own 'custom' packages in the installation. Maybe ones you have compiled yourself, e.g. from the AUR, or modified versions (fixes or customizations) of standard packages. To do this you need to put your packages in a directory and run gen-repo - which requires python - on this directory (run it without arguments to get usage instructions). Then place an entry for this new repository in your 'pacman.conf' (in the profile or else in the working directory). If your packages replace some in the existing repositories, your custom repository needs to come before those repositories in 'pacman.conf'. Any packages you want installed now just need to be listed in addedpacks.

Larch also sets up a pacman.conf file which contains this little nugget of information:

# An example of a custom package repository. See the pacman manpage for
# tips on creating your own repositories.
#[custom]
#Server = file:///path/to/custom

This sounds promising and looks straightforwards. So I put my packages in a directory, run gen-repo and make a change to pacman.conf. Only I can't fucking find gen-repo. I mean it is not in the directory I installed larch into. Where the fuck can it be? I eventually trace it to ./larch/run/ where I find it is actually called gen_repo, not gen-repo. Fan-fucking-tastic waste of time.

So I then run the command on the directory I have assembled my custom packages in. It makes a new file in that directory called nameofdirectory.db.tar.gz.

Right so I ask you now - how do I "place an entry for this new repository in" my pacman.conf file? I try referencing this new file directly in the Server: line. That doesn't work. I try just making the server line link to the directory the new file is in. That still doesn't work.

I eventually discover, through trial and error no less, that what I should have been doing was to have the Server: line point to the directory the new file was in, uncomment the line #[custom] above AND change the word 'custom' in it to the NAME of the new file LESS the .db.tar.gz bit. Oh - of course, silly me, how fucking simple. I mean, it is all laid out so clearly in those helpful manual files. All these steps are so fucking transparent I nearly walked right into them.

Give me fucking strength. Is it something to do with linux? Are the developers so fucking delighted to get their software to actually work that they piss off down the pub as soon as it compiles? With the inevitable result that they are shit-faced drunk when it comes to writing the documentation? And then, THEN, when you ask a question you are told to RTFM? Really? Well stick your RTFM right UYFA.

Setting Default Applications in Arch LXDE

LXDE being a very basic desktop environment, there is not much in the way of GUI tools to change your default applications. So for instance when you double click on a PDF does that open in pdfviewer or evince? Or, in a staggering approach to logic, GIMP?

You need to know two things about a file - what its MIME type is, and what application is set to run that file type.

You find out the first element by using the filename of a type you are interested in, in this command in terminal:

xdg-mime query filetype filewithatypeIaminterestedin.pdf

The output will look a bit like this:

application/pdf; charset=binary

For our present purposes, the first part of the response is the important bit. It tells us that the MIME type is "application/pdf". You can now run the following to find out what application is set to run this:

xdg-mime query default application/pdf

Where "application/pdf" is obviously whatever was spat out by the previous command. The results of this command, should be a .desktop file. This is the file in /usr/share/applications which has all the important information about an application. To change this you run the following command:

xdg-mime default epdfview.desktop application/pdf

Mount Windows Shares in Arch

Oh for fucks sake this is difficult. It should be easy, really it should be easy, but the combination of shitty documentation, and crap network authentication standards leads to a mess.

It should work, on a temporary basis with these commands:

mkdir /media/network
mount -t cifs "//server/share/" /media/network -o username=myusername,password=mypassword

There should be a way to do all this automatically with smbnetfs, but that software is currently fucked.

Otherwise, this might have stood a chance:

pacman -S smbnetfs
modprobe fuse
nano /etc/fuse.conf #uncomment 'user_allow_other'
/etc/rc.d/smbnetfs start

This does stand a chance, actually. Just not with anything that should, god forbid, use some kind of username/password security. Configuration is in:

/etc/smbnetfs/.smb/smbnetfs.conf

Which failing a forced manual mount would look like this:

cd /mnt/smbnet/DOMAIN:myusername:mypassword@server

But that fails with the delightfully informative "Transport endpoint is not connected", which makes about as much intuitive sense as "Your wurfle strip has sturbified, you must re-cognificate your panzel-struder".

Installing Dropbox in Arch

There is this really useful bit of software called Dropbox, which syncs a directory on your machine with a network server and your other machines. It also handles version control and backups. It runs on XP and Linux and as such is very useful.

On Ubuntu it will install perfectly happily, but on other distributions it takes a little bit more work. The following instructions work for Arch running the LXDE desktop.

Step One.
Download the Linux version from here. Then extract the contents into your home, or ~/ folder. The contents should just be a folder called .dropbox-dist.

Step Two.
Download two command line utilities to setup the non-ubuntu version by running these commands in terminal:

wget http://dl.getdropbox.com/u/6995/dbmakefakelib.py
wget http://dl.getdropbox.com/u/6995/dbreadconfig.py

Step Three.
Make a folder in your home directory to store the files being shared by running this command in terminal:

mkdir ~/Dropbox 

Step Four.
Run the two scripts that you downloaded earlier to get an ID code for the machine that you are using. The first script test runs Dropbox to generate the local databases with your host_id. If the dropbox program pops up, just ignore it. It will be have quite flakily. Rely on the command line, it will tell you when 15 seconds have passed. Just close dropbox at that stage, and run the next command. If you get any error codes when running the first command, try running it whenyou are offline - i.e. disconnect from the internet.

python dbmakefakelib.py
python dbreadconfig.py 

Copy the host_id from the subsequent text output.

Step Five.
Open a browser window and use this link (where HOSTID is the host_id you copied in the previous step):

https://www.getdropbox.com/cli_link?host_id=HOSTID

Log in with your user name and password.

Step Six.
Desktops which follow the free desktop system store information for their application menus in .desktop files which are then automatically assembled into a menu structure. You need to setup a menu icon for Dropbox by running the following command in terminal (you NEED to make sure to change the USER below to the name of your user account):

echo '[Desktop Entry]
Name=Dropbox
GenericName=Network Storage
Comment=Secure backup, sync and sharing made easy
Exec=/home/USER/.dropbox-dist/dropboxd
Icon=/usr/share/pixmaps/dropbox.png
Terminal=false
Type=Application
Categories=Network;' | sudo tee -a /usr/share/applications/dropbox.desktop

That command will make a new file in /usr/share/applications/ called dropbox.desktop. That's the folder which LXDE uses. Other distributions and Desktop Environments may vary. You will find icons for all other installed applications in the same folder. Important note - installing the .desktop folder here will make the application appear in all users menus. It is possible to install it to a personal folder in home, which may be preferable.

Step Seven.
To make it look nice you will need an icon, which you can get and copy to the right place by running these commands:

wget http://aur.archlinux.org/packages/dropbox/dropbox/dropbox.png
sudo mv ./dropbox.png /usr/share/pixmaps/dropbox.png

Step Eight.
You will want Dropbox to run when your user logs in, so that it is available automatically. The free desktop model makes provision for this and you can set it up by running these commands:

mkdir  ~/.config/autostart
cp /usr/share/applications/dropbox.desktop ~/.config/autostart/ 

The first command [m]a[k]es a [dir]ectory in your home (~) folder called config with another folder inside called autostart. The [.] before config means the folder is hidden.
The second command [c]o[p]ies the desktop file we made in Step Six to the autostart folder, causing it to be run when the user owning the home directory logs in.

Step Nine.
You can now run Dropbox from the menu, where an Icon has magically appeared, or restart your machine. All the configuration of the client should have been achieved by Step Five, so it should start syncing right away.