Thoughts about Medium

The more I read Medium, the more I like it. For a change, a site focusing on essays on diverse topics without hyperbolic “You Won’t Believe What Scientists Have Found Inside A Grapefruit!” titles, complete with “Stories You Might Like” sections at the bottom (IFLS, I’m looking at you. You’re great, but stop using third-party traffic referers, please).

Medium’s presentation is clean, text-focused (no annoying sidebars with Things I May Like) and the typography is wonderful. Its homepage lists popular/highly-rated articles beautifully. This article (one of theirs) explains it far better than I could: https://medium.com/who-what-why/fonts-have-feelings-too-1523564d966c

If that weren’t enough, they are also committed to honouring Do Not Track headers – if you don’t want your browsing through their site to be analysed by their analytics packages, then it won’t be. Source:https://medium.com/policy/how-we-handle-do-not-track-requests-on-medium-f2b4b4fb7c5e

Here are some articles I’ve read lately and would thoroughly recommend:

https://medium.com/matter/sex-is-sex-but-money-is-money-e7c10091713f
https://medium.com/teaching-learning/what-i-learned-about-misogyny-on-the-internet-90002b3c962c
https://medium.com/matter/this-is-the-last-thing-youll-ever-need-to-read-about-sexism-in-tech-56b9a3a77af0
https://medium.com/message/how-to-be-polite-9bf1e69e888c

Thoughts about Medium was originally published on antispin

Grok patterns in Logstash

After posting a set of postfix and sendmail Grok patterns, I’ve had a request to explain how to implement Grok patterns in Logstash. So, here we go.

I’m going to make some assumptions about your installation of Logstash – on a typical Debian install, assuming you installed from the Elasticsearch PPA (hint: you should be doing this), your Logstash configs will be in /etc/logstash/conf.d/ or something of the sort.

|/etc/
|-logstash/
|--conf.d/
|---inputs.conf
|---filters.conf
|---outputs.conf
|--patterns/
|---sendmail.grok
|---postfix.grok

As you can see, the Grok patterns go in /etc/logstash/patterns/ in my case. You can realistically put them anywhere you like, providing the logstash process can access the location.

Anyway, if you want to make use of any Grok pattern (assuming it’s valid), it’s a fairly straightforward operation:

filter {
  grok {
    patterns_dir => "/etc/logstash/patterns"
    pattern => "%{SENDMAIL}"
    named_captures_only => true
  }
}

The named_captures_only will tell Grok to only capture fields that are named in your Grok pattern and discard the cruft – useful when you want to extract a few key metrics from an event.

If you look at the Sendmail grok file I posted here, you can see how it’s being referenced above. This method is deprecated, but it still works for me, so that’s what I’m sticking with.

You can get creative and only invoke Grok for certain types of events by using an

if [type] == "something" {
  grok {
    patterns_dir => "/etc/logstash/patterns"
    pattern => "%{SOMEPATTERN}"
    named_captures_only => true
  }
}

Hope this helped!

Grok patterns in Logstash was originally published on antispin

Zimbra 8.5 EWS

Zimbra have recently released Zimbra Collaboration Suite 8.5 (JudasPriest).

One of the most-hyped features of 8.5 is native support for Exchange Web Services (EWS), meaning Macs and Outlook clients can natively connect to EWS instead of using the Zimbra Connector or IMAP.

After laying the groundwork for doing the upgrade – moving data around, system updates, installing the LTS Enablement pack from Canonical on Ubuntu 12.04 to upgrade the kernel among other things, we were ready for the upgrade to 8.5.

Watch out for Puppet

If your Zimbra box is managed by Puppet and if Puppet manages your /etc/sudoers file, you’ll want to stop the agent before running the upgrade. The reason for this is that 8.5 has additional commands that the Zimbra user needs to be able to run with elevated privileges. It’ll update your sudoers file as part of the upgrade, but there’s a danger that Puppet will roll it back which can seriously cock up your installation.

EWS and Touch Client

Do not work out of the box.

It turns out that if your license was purchased before the 1st of September 2014, you are not eligible to use the EWS functionality, despite enabling it in the CoS settings in Zimbra.

Needless to say, I am not currently best-pleased with Zimbra for effectively locking out users who have purchased perpetual licenses and a support pack which is supposed to provide access to upgrades. According to them, however, it seems that since EWS was not available as a feature at the time of purchase of the license, you need to pay extra to get it.

Anyone else having this problem with Zimbra? Anyone else been bitten by Zimbra’s sneaky pricing tactics?

Update

Zimbra have come back to us and have said the following:

Outlook for Mac is not an upgrade feature but an add-on.  Because there is a royalty associated with it, Zimbra chose to not increase prices for the product editions for everyone to accommodate that expense but rather to simply allow those companies who needed it, the ability to purchase it separately.  

Which is interesting, given that it’s described as a “New Feature” in their 8.5.0 upgrade guide

Update 2

Twitter user @jorgedlcruz has done a bit of asking around and has let me know the score.
Seems that EWS is an optional feature and the feature matrix reflects this. But it’s only available to resellers and internally.

Zimbra 8.5 EWS was originally published on antispin