More office365 Annoyances

I have been using IQTell as my todo list management and email client.  Within the past month or so, they added the ability to handle calendar invites, which I thought was completely awesome.  Except it didn’t work on Office365.  Well, it worked as long as the appointment was sent from Gmail or a phone, but not from outlook.  Instead I got a link that forced me to login to Office365 to download the iCal content.

When the account was added to IQTell, it was added as an Exchange account.  Which, by default, checks via IMAP.  It turns out if you override the default and instead connect via Exchange Web Services the calendar appointments would work.  Awesome!  Except, it didn’t always work, because this utilizes API calls, of which there is some arbitrary, unpublished limit.  So IQTell was intelligently adding wait time to the requests so the API calls would work.  That worked, but made the connections horribly slow.

IQTell support then linked me to some seemingly useful documentation: And after fiddling around with an expired password and the insanity that is PowerShell, I managed to get the settings set.  Except, according to the documentation “ImapForceICalForCalendarRetrievalOption=False means all meeting requests are in iCal format”.  Which is incorrect.  …ForceIcal…=True, does in fact force iCal as it sounds contrary to what the docs say.

So I get that far and it still didn’t work.  In Microsoft wisdom,  setting these options doesn’t mean anything until you tell it to “ignore the defaults”

I went ahead and set the values for pop and IMAP.  The whole string that actually worked was:

Set-CASMailbox –identity user@domain.com –PopUseProtocolDefaults:$FALSE –ImapUseProtocolDefaults:$FALSE –PopForceICalForCalendarRetrievalOption:$TRUE –ImapForceICalForCalendarRetrievalOption:$TRUE

While it wasn’t actually their problem, IQTell support was able to get me to answer that worked.

Rdio and Linux

I have been using Rdio for about a year now.  While it has some holes with older music, all-in-all I am very happy with the service.

Rdio uses a very capable web player so you can play your music in your browser.  That’s perfect, however the one thing missing is support for multimedia keys.  After searching around for a Linux app that supported multimedia keys, I discovered that I could roll my own very easily using chrome, xbindkeys, and xdotool.

xbindkeys and xdotool

These two apps are the heart of what makes this work.  xbindkeys grabs the input keys, and executes xdotool which let’s us operate on specific windows and send key strokes to them.  So they both need to be installed first.  I am using Fedora, but I presume these exist as packages in whatever Linux you are using.

sudo yum -y install xbindkeys xdotool

Chrome

The first thing is to create an “application shortcut” for chrome.  Do this by doing the following:

  1. Open Chrome
  2. Browse to http://rdio.com
  3. Click the tool icon thingy (three lines in the upper-right)
  4. Click Tools
  5. Click “Create Application Shortcuts”
  6. Choose where you want the shortcut to go.  Really we are just looking for it to create the .desktop entry so that it will show up in Gnome’s overlay mode so the default Desktop is all that’s needed.

At this point there is a perfectly functional webpage acting like an application.  It should run if you hit the SUPER key and type rdio.

Xbindkeys Config

Below is my current config file.  In order to get the keys to send, you need to run

xbindkeys -mk

This will run xbindkeys in a window, make sure that window is active and hit the key you want to bind.  The code for that key will then show in the console.  Then you just write the config with the command that you want to be run, followed by the key (that we grabbed before).  This is where xdotool comes in.  We are going to search for a window named Rdio, and send the keys that perform the multimedia functions.  So for example, when we hit the media key Play/Pause, it will send a space to the window named Rdio.

#keystate_numlock = enable
#keystate_capslock = enable
#keystate_scrolllock= enable

#Media keys for my fake rdio app (chrome --app)
"$(grep '^Exec' rdio.desktop | tail -1 | sed 's/^Exec=//' | sed 's/%.//')"
    Mod2 + XF86AudioMedia
"xdotool key --window $(xdotool search --name Rdio | head -1) space"
    Mod2 + XF86AudioPlay
"xdotool key --window $(xdotool search --name Rdio | head -1) Left"
    Mod2 + XF86AudioPrev
"xdotool key --window $(xdotool search --name Rdio | head -1) Right"
    Mod2 + XF86AudioNext

Gnome Configuration

By default, Gnome is going to have the keys bound to some multimedia key default.  And they are probably the same ones you are trying to bind.  So you have to disable the Gnome keybindings so xbindkeys can grab them instead.  To do this:

  • Go to settings
    • Either by clicking the icons in the upper-right hand side and clicking the tools icon
    • or…hit the SUPER key to go to overlay mode and search for settings
  • Choose the keyboard under Hardware
  • Click the Shortcuts tab
  • Click “Sound and Media”
  • Go to each key you want to grab from xbindkeys and when it prompts you for “new accelerator” you can either hit Backspace to clear the setting.

Success! (hopefully)

At this point you should have a fully functional web app that responds to multimedia keys.

MySQL Multi-source part II

There seems to be a major issue with what I was planning to do using multi-source replication and what the developers seem to expect people to do.  I believe the problem is summed up in “This feature does not do any additional conflict detection and resolution” (https://dev.mysql.com/worklog/task/?id=1697)

The basic problem is that the expectation is replicated databases will all have different names.  Which would have certainly been the case in previous replication methods because master/slave was one to one and there could only be one master per host.  However multi-source has the implication that there may be overlapping database names.  But thanks to what I believe is encompassed in the above quote, there is no consideration on the slave side to deal with that.

There is a concept of rewriting database names, but that is a global configuration which still won’t work in this scenario.  It would need to support the “for channel=” command, which currently it does not.

So multi-source replication is pretty cool, but doesn’t work for my use case.  At least not at this point.

MySQL Multi-source replication

Following this post (http://www.mysqlperformanceblog.com/2013/10/02/mysql-5-7-multi-source-replication/) I was able to get multi-sourced replication working.  And the concept is pretty cool.  The plan was to have a bunch of MySQL instances replicated to a single box for backup and reporting purposes.  The problem is that multi-source replication works basically like regular replication and each table needs to be unique.

The setup I’m working with has multiple instances that are all identical as far as layout goes, only the data is different.

Next step is checking out MariaDB replication.

CrashPlan

I have been trying for quite a while to get CrashPlan to work on my Fedora 20 installation.  I’ve searched the internet many times and found suggestions of changing graphics libraries and java settings.  All things that haven’t worked.  Today I found https://support.code42.com/CrashPlan/Latest/Troubleshooting/CrashPlan_Client_Closes_In_Some_Linux_Installations which corrected the issue.

Annoying, but glad it is working now.