How can I see the TLS (SSL) certificates that my RADIUS server is using, to make sure it is sending the correct certificate and chain?
I am implementing 802.1x authentication with a RADIUS server, but I have certificate acceptance problems on some supplicants (clients). I would like to see the certificates sent by the server in an easy way, similar to how you use openssl s_client to debug TCP TLS traffic.
To get rid of the "via" and "on behalf of" headers in Gmail and Outlook, do I need to set both the DKIM and the SPF records, or are DKIM records enough?
We recently changed our SMTP provider from AuthSMTP to Mandrill. By default Mandrill does bounce handling itself, so the Return-Path is set to mandrillapp.com. In the SPF check I saw that it checks the SPF records of mandrillapp.com instead of ourdomain.com, probably because of this Return-Path. For DKIM it checks ourdomain.com.
During testing I noticed that the "via header" was already gone in Gmail when only the DKIM record was added, but not the SPF record yet. So this makes me think only adding DKIM is enough for this header?
The actual reason I'm asking this is that we are temporarily running against the 10 DNS lookup limit for SPF, because we are trying out different tools, so if I can continue without completely correct SPF records now (ending with ~all) that would be handy.
Is the order in which Nginx includes configuration files fixed, or random? Apache explicitly states wildcard characters are expanded in alphabetical order. With Nginx it seems this does not apply, and the manual says nothing about it.
In my setup, 20_example.com was included before 00_default, which defeats my purpose of defining shared directives (like log formats) there.
I want to run Trac in Gunicorn, behind Nginx. Nginx handles user authentication via LDAP (which works), but I can't get the REMOTE_USER passed to Trac.
For uWSGI I would configure Nginx like this (tested and it works):
uwsgi_param REMOTE_USER $remote_user;
For Gunicorn I could not find a similar configuration directive. I have tried setting the header, but it doesn't seem to change anything:
proxy_set_header REMOTE_USER $remote_user;
There is an entry in the Trac wiki about this, noting that "the wsgi entry point does not handle [...] authentication", and a workaround to handle Basic Authentication with a local password file, which is not what I need. Do I need to change my entry point to pass this REMOTE_USER header to the right environment variable? Currently it's just this:
import sys
import os
sys.stdout = sys.stderr
os.environ['TRAC_ENV'] = '/path/to/my/trac'
import trac.web.main
application = trac.web.main.dispatch_request
If you provide a service on two servers to ensure high-availability, is it better to configure them in exactly the same way, of instead should you introduce slight differences to prevent "freak configuration" errors?
We host a Django-based website on a stack of Linux (Ubuntu LTS), Nginx, Apache and Python WSGI, duplicated on three servers behind a load balancer. Currently they are hosted in the Amazon cloud, but we might move to our own datacenter in the future. We recently had an issue on all three servers which was only solved by upgrading the kernel, which makes us think it was an incompatibility between this specific version of the kernel and the physical hardware that Amazon might have started using at the point.
This made me think: would it be better to keep all machines on exactly the same configuration (easier management?), or should we instead keep things slightly difference, so that an incompatibility between two components will only manifest itself on one machine and not all of them, keeping your website in the air?