My configuration is pretty simple and really cool in my opinion. All of my SSL is terminated on my reverse proxy so I don’t have to manage certificates inside my network at all. While this configuration isn’t particularly exotic, I thought it might be worth sharing anyway. I bet someone will someday find good use from it:

server {
   listen  80;
   server_name     owncloud.example.net;
   rewrite ^       https://$server_name$request_uri? permanent;
}

server {
        listen       443;
        server_name  owncloud.example.net;

        ssl                  on;
        ssl_certificate      /etc/nginx/conf.d/ssl/owncloud.example.net.bundle.crt;
        ssl_certificate_key  /etc/nginx/conf.d/ssl/owncloud.example.net.key;
# Ridiculously high timeout due to long requests for uploads
        ssl_session_timeout  5m;

        ssl_protocols  SSLv2 SSLv3 TLSv1;
        ssl_ciphers  HIGH:!aNULL:!MD5;

        access_log  /var/log/nginx/owncloud.example.net.log main;

        proxy_redirect  off;
        proxy_set_header        Host    $host;
        proxy_set_header        X-Real-IP       $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_buffering         off;
        proxy_set_header Connection     "Keep-Alive";

# Allow uploads up to 16GB in size
        client_max_body_size    16000m;

# transparently handle requests to server root
        location / {
                rewrite ^ https://owncloud.example.net/owncloud$request_uri redirect;
        }

        location /owncloud {
# owncloud.example.local is your actual owncloud server inside your network
                proxy_pass http://owncloud.example.local:80/owncloud;
        }

}

This works, not only the web client but also the mobile and desktop clients. I put in the neat rewrite rule so that users can just type the server name and don’t have to get excited about the owncloud URI component. ownCloud is installed using default configurations on the internal server, no complex configurations or anything there. I love nginx reverse proxying.

Cyrus IMAP server is installed and authenticating just fine using saslauthd to my Active Directory:

/etc/imapd.conf:

...snip...
sievedir: /var/lib/imap/sieve
sendmail: /usr/sbin/sendmail
sasl_pwcheck_method: saslauthd
sasl_mech_list: PLAIN LOGIN
...snip...

/etc/sysconfig/saslauthd:

SOCKETDIR=/run/saslauthd
MECH=ldap
FLAGS="-r"

However I can’t get my sieve clients including sieveshell to authenticate:

[root@mailserver /]# sieveshell --user="first.last@example.com" --authname="first.last@example.com" localhost
connecting to localhost
connect: Connection refused
unable to connect to server at /bin/sieveshell line 170.

Telnet-ing in yielded no auth mech’s presented:

[root@mailserver /]# telnet localhost sieve
Trying ::1...
Connected to localhost.
Escape character is '^]'.
"IMPLEMENTATION" "Cyrus timsieved v2.4.17-Fedora-RPM-2.4.17-8.el7_1"
"SIEVE" "comparator-i;ascii-numeric fileinto reject vacation imapflags notify envelope relational regex subaddress copy"
"STARTTLS"
"UNAUTHENTICATE"
OK

No auth mech’s listed, e.g. PLAIN, LOGIN, etc. What gives? The search string “timsieved sasl_auth_mech” yielded 3 results on Google, luckily this page was one of them. How often is it simply that some package you need isn’t installed?

[root@mailserver /]# yum -y install cyrus-sasl-plain

That’s it:

[root@mailserver /]# telnet localhost sieve
Trying ::1...
Connected to localhost.
Escape character is '^]'.
"IMPLEMENTATION" "Cyrus timsieved v2.4.17-Fedora-RPM-2.4.17-8.el7_1"
"SASL" "PLAIN LOGIN"
"SIEVE" "comparator-i;ascii-numeric fileinto reject vacation imapflags notify envelope relational regex subaddress copy"
"STARTTLS"
"UNAUTHENTICATE"
OK

Another takeaway I learned – if you want disable TLS for just Cyrus sieve adjust your /etc/cyrus.conf as such:

  sieve         cmd="timsieved" -C /etc/sieve.conf listen="sieve" prefork=0

And just modify the /etc/sieve.conf file to suit your needs. I know this has caused me issues in the past and never knew it could be tuned separate of imapd.

root@oi-storage:~# zfs get -Hp volsize pool0/kvm/kvmdomain
 pool0/kvm/kvmdomain       volsize 42949672960     local

Well of course that isn’t big enough…

root@oi-storage:~# zfs set volsize=42956488704 pool0/kvm/kvmdomain

No problemo, now just rescan on the Linux side right?

[root@linux-hv ~]# iscsiadm -m node --targetname iqn.2010-09.org.openindiana:02:6640d696-90b3-6709-804e-da40a0ffffff -R
[root@linux-hv ~]# dmesg
  ...
[1329034.807613] sd 4:0:0:0: [sdc] 83886080 512-byte logical blocks: (42.9 GB/40.0 GiB)
  ...

Hmm… that didn’t do it (512 * 83886080 = 42949672960). I banged around a little bit and found what I was missing:

root@oi-storage:~# sbdadm modify-lu -s 42956488704 600144f0340b80c719ff570bb7460001

Then the Linux rescan yielded more useful results:

[root@linux-hv ~]# dmesg
  ...
[1340836.125483] sdc: detected capacity change from 42949672960 to 42956488704

Thus I spent no doubt a good 4 hours or so troubleshooting/uninstalling/fiddling/thissing/thatting the Bluetooth device and software on my trusty old beast. There are a few forum posts indicating this and that, try Lenovo software, try Broadcom’s update, try old drivers in compatibility mode. It all sucked.

Backing up a step it’s worth outlining the symptoms – after the Win10 upgrade both my Microsoft Sculpt Bluetooth mouse and my Microsoft Curve Bluetooth keyboard worked somewhat, but the features weren’t right. I unpaired and discovered no ability to re-pair.

All of my searching led me here – a forum post more about Windows 8, but similar problem. The solution is to use some older Lenovo software.

No compatibility, no BS, it just worked. I did have to unpair then re-pair when finished. Also at the end of the install it did indicate failure, but that is apparently not the case.

Quick link: http://tinyurl.com/b8fptwr

Now back to being angry about my missing boat parts.