A recent update broke my WordPress theme. I’ve used the same theme for almost 10 years and it was starting to be a pain to keep updated and working with newer WordPress versions. So I decided to put up this simple theme until I get a new theme picked out and up and running.
Update November 2018:
A reader contacted me and pointed out that removing the {} around DKIM_DOMAIN solves the errors in the original example I found and had problems using. I’ve updated the code below (line 8) to reflect those changes in case anyone ends up here via google.
He also shared a nifty way to make selector rollovers easier by adding them to the filename:
1 2 3 4 5 6 7 8 | DKIM_SELECTOR = whatever DKIM_FILE =/etc/exim4/dkim/DKIM_DOMAIN.pem.DKIM_SELECTOR DKIM_PRIVATE_KEY = ${if exists{DKIM_FILE}{DKIM_FILE}{0}} With the format of the key files being .... /etc/exim4/dkim/example.org.pem.previousselector /etc/exim4/dkim/example.org.pem.whatever |
And last but not least an elegant way to populate the DKIM_DOMAIN variable: https://bugs.exim.org/show_bug.cgi?id=1019
Original Posting:
I was recently setting up SPF, DKIM and DMARC for multiple domains and was having trouble getting Exim to sign emails for the different domains. I found an article here explaining the steps. But I kept getting the following error in my exim logs:
failed to expand dkim_private_key: missing or misplaced { or }
The suggested configuration was the following:
1 2 3 4 5 6 7 8 9 10 11 | DKIM_CANON = relaxed DKIM_SELECTOR = 20150726 # Get the domain from the outgoing mail. DKIM_DOMAIN = ${sg{${lc:${domain:$h_from:}}}{^www\.}{}} # The file is based on the outgoing domain-name in the from-header. DKIM_FILE = /etc/exim4/dkim/DKIM_DOMAIN.pem # If key exists then use it, if not don't. DKIM_PRIVATE_KEY = ${if exists{DKIM_FILE}{DKIM_FILE}{0}} |
I’m not quite sure why, but Exim was having trouble using the macros in the following macros, so I ended up changing it to the following snippet instead. If you don’t use DKIM_FILE you can omit it. Also you might want to set DKIM_STRICT to true if you published a DMARC policy that will reject or quarantine email failing the DKIM tests (unset, or “false” tells Exim to send the message unsigned if it ran into problems signing the email). The default setting for DKIM_CANON is “relaxed“, so it also can be omitted.
1 2 3 4 5 6 | DKIM_CANON = relaxed DKIM_STRICT = false DKIM_SELECTOR = 20160724 DKIM_DOMAIN = ${lc:${domain:$h_from:}} DKIM_FILE = /etc/exim4/dkim/${lc:${domain:$h_from:}}.pem DKIM_PRIVATE_KEY = ${if exists {/etc/exim4/dkim/${lc:${domain:$h_from:}}.pem} {/etc/exim4/dkim/${lc:${domain:$h_from:}}.pem}} |
Other than that, just make sure the exim process has permissions to access the dkim directory and certificate files and everything should work nicely.
When using OpenVAS in larger environments (e.g. lots of tasks and/or lots of slaves) you may have noticed the manager controlling all the slaves/scans can get sluggish or unresponsive at times. In my experience it is often due to the different processes waiting for an exclusive lock on the sqlite database. Fortunately OpenVAS 8 and above also supports using PostgreSQL as a database backend instead of sqlite. I think OpenVAS 7 also had support built-in, but it was still considered experimental.
Documentation on how to use PostgreSQL as the backend is in the OpenVAS svn repository. In a nutshell it is mainly adding -DBACKEND=POSTGRESQL to your cmake when you compile the manager (my cmake line is cmake -DCMAKE_INSTALL_PREFIX=/ -DCMAKE_BUILD_TYPE=Release -DBACKEND=POSTGRESQL ..). I generally only compile the master with PostgreSQL support and leave the slaves to use sqlite (since they don’t have as many concurrent accesses to their database). The documentation also steps you through the permissions you need to set up in PostgreSQL so it can be used by OpenVAS. Don’t forget to make the system aware of your OpenVAS libraries, in my case since I install OpenVAS to / I put /lib64/ in my /etc/ld.so.conf.d/openvas.conf file and then execute ldconfig.
One issue you may run into is migrating data from sqlite to PostgreSQL. There is a migration script in svn that can migrate the data, but it only works for a few older database versions. I assume OpenVAS 9 will contain an updated version of the script when it is released, but until then I wrote a script that uses the OMP protocol to export/store/import some of the settings. Since it only uses OMP to communicate with the master it is backend agnostic. You can use it to export the sqlite data and import it back into a manger using the PostgreSQL backend. It also means that it can only access data you can export via OMP (so no credential passwords/keys). The script will keep references intact (which tasks uses which target/schedule/…). The list of what it exactly imports/exports is on the github page: github.com/ryanschulze/openvas-tools
Lately I’ve run into issues with different versions of ansible (1.9 handling async better, 2.x having more modules and handling IPv6 better) and having to test playbooks and roles against different versions to make sure they work. TO make life easier I put this little function in my .bashrc to switch back and forth between ansible versions. It checks out the specified version from github if it needs to, and switches over to it (just for that terminal, not the system). Usage is straight forward ansible_switch <branch> , i.e. ansible_switch 2.1 (or whatever branch you want, here is a list of all branches).
It is currently limited to stable branches, but you can change line 6 from stable- to whatever you want (or remove the prefix completely). If you have a github account you also may want to change from https to ssh by using the git@github.com:ansible/ansible.git checkout URL.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | ansible_switch() { local version=${1:-} local srcpath="${PWD}" test -d ~/git || mkdir ~/git ; cd ~/git if [[ ! -d ansible_${version} ]] ; then git clone -b stable-${version} --recursive https://github.com/ansible/ansible.git ansible_${version} fi git pull ansible_${version} export MANPATH="${MANPATH//$HOME\/git\/ansible_?.?\/docs\/man:/}" export PYTHONPATH="${PYTHONPATH//$HOME\/git\/ansible_?.?\/lib:/}" export PATH="${PATH//$HOME\/git\/ansible_?.?\/bin:/}" source ansible_${version}/hacking/env-setup cd "${srcpath}" } |
A quick one today. The following ansible tasks check if a server needs to be rebooted, reboots it, and then waits for it to come back online. Easy to fire off during a maintenance after updating packages.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | - name: reboot server if /var/run/reboot-required exists command: shutdown -r now args: removes: /var/run/reboot-required - name: wait until rebooted local_action: wait_for host={{ inventory_hostname }} port=22 state=started delay=30 - name: give sshd a few seconds to start up fully raw: echo ssh subsystem online register: result until: result.stdout.find("ssh subsystem online") != -1 retries: 50 delay: 10 |