Planet HantsLUG

Syndicate content
Planet HantsLUG - http://hantslug.org.uk/planet/
Updated: 24 min 37 sec ago

Andy Smith: Stewart Lee interviewed on The Comedian’s Comedian Podcast

Wed, 28/03/2018 - 11:51

Really good interview with Stewart Lee on The Comedian’s Comedian Podcast with Stuart Goldsmith. It’s lengthy—over 2 hours when Goldsmith’s extras are tacked on—and not a work of comedy in itself, so don’t listen if you’re expecting a laugh-fest. It is an actual interview with the person, not the character, inasmuch as they can ever be fully separated.

Also don’t read the description and be put off by how much Goldsmith talks him up in it; it’s a good humble interview that goes into the craft of it.

Some of the incidents he mentions in the interview were either filmed professionally or caught on camera phone and if you are a Stewart Lee fangirl like me then they’re interesting to watch in light of his comments about them.

1. Glaswegian audience member gets hung up on Lee’s Caffe Nero card during DVD recording.

2. “Stewart Lee destroys a heckler” which Lee complains is misnamed because he doesn’t set out to destroy hecklers, but rather to simply address their concerns, in character.

3. “I think he’d feel flattered to be misquoted by me“. Out of context on YouTube it would be easy to mistake this for a genuine (but very silly) debate, but it was entirely written by Lee and is presented in-character as part of a show, as a justification by the character of Stewart Lee as to why he can mock and misquote Russell Brand.

4. “There’s just so much now it’s unmanageable … it had a positive effect on the act in that I just decided to become more like the thing they hate.” Lee’s now-frozen file of abusive online critiques is also worth linking to.

Categories: LUG Community Blogs

Andy Smith: Using a different theme for Mediawiki’s SyntaxHighlight extension

Tue, 20/03/2018 - 02:51

Probably the best syntax highlighting plugin for Mediawiki at the moment is the one simply called SyntaxHighlight. It uses Pygments to do the heavy lifting. What sets it apart from the other extensions is that it supports line numbers and picking out highlighted lines.

Unfortunately the default style (theme) is dark-on-light whereas for most of my syntax highlighting I am giving examples of either shell sessions or code. All my shell sessions and code are viewed as light-on-dark, so I would prefer that the wiki’s syntax highlighting followed suit.

I spent quite a while messing about with editing the extension itself but to little effect, until Robert pointed out that I just needed to edit the Common.css file inside the wiki itself. Then you get some decent results.

I used something like this to generate the correct CSS for the “native” style:

$ ./extensions/SyntaxHighlight_GeSHi/pygments/pygmentize -S native -f html|sed -e 's/^/.mw-highlight > pre /' .mw-highlight > pre .hll { background-color: #404040 } .mw-highlight > pre .c { color: #999999; font-style: italic } /* Comment */ .mw-highlight > pre .err { color: #a61717; background-color: #e3d2d2 } /* Error */ .mw-highlight > pre .esc { color: #d0d0d0 } /* Escape */ .mw-highlight > pre .g { color: #d0d0d0 } /* Generic */ .mw-highlight > pre .k { color: #6ab825; font-weight: bold } /* Keyword */ .mw-highlight > pre .l { color: #d0d0d0 } /* Literal */ .mw-highlight > pre .n { color: #d0d0d0 } /* Name */ .mw-highlight > pre .o { color: #d0d0d0 } /* Operator */ .mw-highlight > pre .x { color: #d0d0d0 } /* Other */ .mw-highlight > pre .p { color: #d0d0d0 } /* Punctuation */ .mw-highlight > pre .ch { color: #999999; font-style: italic } /* Comment.Hashbang */ .mw-highlight > pre .cm { color: #999999; font-style: italic } /* Comment.Multiline */ .mw-highlight > pre .cp { color: #cd2828; font-weight: bold } /* Comment.Preproc */ .mw-highlight > pre .cpf { color: #999999; font-style: italic } /* Comment.PreprocFile */ .mw-highlight > pre .c1 { color: #999999; font-style: italic } /* Comment.Single */ .mw-highlight > pre .cs { color: #e50808; font-weight: bold; background-color: #520000 } /* Comment.Special */ .mw-highlight > pre .gd { color: #d22323 } /* Generic.Deleted */ .mw-highlight > pre .ge { color: #d0d0d0; font-style: italic } /* Generic.Emph */ .mw-highlight > pre .gr { color: #d22323 } /* Generic.Error */ .mw-highlight > pre .gh { color: #ffffff; font-weight: bold } /* Generic.Heading */ .mw-highlight > pre .gi { color: #589819 } /* Generic.Inserted */ .mw-highlight > pre .go { color: #cccccc } /* Generic.Output */ .mw-highlight > pre .gp { color: #aaaaaa } /* Generic.Prompt */ .mw-highlight > pre .gs { color: #d0d0d0; font-weight: bold } /* Generic.Strong */ .mw-highlight > pre .gu { color: #ffffff; text-decoration: underline } /* Generic.Subheading */ .mw-highlight > pre .gt { color: #d22323 } /* Generic.Traceback */ .mw-highlight > pre .kc { color: #6ab825; font-weight: bold } /* Keyword.Constant */ .mw-highlight > pre .kd { color: #6ab825; font-weight: bold } /* Keyword.Declaration */ .mw-highlight > pre .kn { color: #6ab825; font-weight: bold } /* Keyword.Namespace */ .mw-highlight > pre .kp { color: #6ab825 } /* Keyword.Pseudo */ .mw-highlight > pre .kr { color: #6ab825; font-weight: bold } /* Keyword.Reserved */ .mw-highlight > pre .kt { color: #6ab825; font-weight: bold } /* Keyword.Type */ .mw-highlight > pre .ld { color: #d0d0d0 } /* Literal.Date */ .mw-highlight > pre .m { color: #3677a9 } /* Literal.Number */ .mw-highlight > pre .s { color: #ed9d13 } /* Literal.String */ .mw-highlight > pre .na { color: #bbbbbb } /* Name.Attribute */ .mw-highlight > pre .nb { color: #24909d } /* Name.Builtin */ .mw-highlight > pre .nc { color: #447fcf; text-decoration: underline } /* Name.Class */ .mw-highlight > pre .no { color: #40ffff } /* Name.Constant */ .mw-highlight > pre .nd { color: #ffa500 } /* Name.Decorator */ .mw-highlight > pre .ni { color: #d0d0d0 } /* Name.Entity */ .mw-highlight > pre .ne { color: #bbbbbb } /* Name.Exception */ .mw-highlight > pre .nf { color: #447fcf } /* Name.Function */ .mw-highlight > pre .nl { color: #d0d0d0 } /* Name.Label */ .mw-highlight > pre .nn { color: #447fcf; text-decoration: underline } /* Name.Namespace */ .mw-highlight > pre .nx { color: #d0d0d0 } /* Name.Other */ .mw-highlight > pre .py { color: #d0d0d0 } /* Name.Property */ .mw-highlight > pre .nt { color: #6ab825; font-weight: bold } /* Name.Tag */ .mw-highlight > pre .nv { color: #40ffff } /* Name.Variable */ .mw-highlight > pre .ow { color: #6ab825; font-weight: bold } /* Operator.Word */ .mw-highlight > pre .w { color: #666666 } /* Text.Whitespace */ .mw-highlight > pre .mb { color: #3677a9 } /* Literal.Number.Bin */ .mw-highlight > pre .mf { color: #3677a9 } /* Literal.Number.Float */ .mw-highlight > pre .mh { color: #3677a9 } /* Literal.Number.Hex */ .mw-highlight > pre .mi { color: #3677a9 } /* Literal.Number.Integer */ .mw-highlight > pre .mo { color: #3677a9 } /* Literal.Number.Oct */ .mw-highlight > pre .sa { color: #ed9d13 } /* Literal.String.Affix */ .mw-highlight > pre .sb { color: #ed9d13 } /* Literal.String.Backtick */ .mw-highlight > pre .sc { color: #ed9d13 } /* Literal.String.Char */ .mw-highlight > pre .dl { color: #ed9d13 } /* Literal.String.Delimiter */ .mw-highlight > pre .sd { color: #ed9d13 } /* Literal.String.Doc */ .mw-highlight > pre .s2 { color: #ed9d13 } /* Literal.String.Double */ .mw-highlight > pre .se { color: #ed9d13 } /* Literal.String.Escape */ .mw-highlight > pre .sh { color: #ed9d13 } /* Literal.String.Heredoc */ .mw-highlight > pre .si { color: #ed9d13 } /* Literal.String.Interpol */ .mw-highlight > pre .sx { color: #ffa500 } /* Literal.String.Other */ .mw-highlight > pre .sr { color: #ed9d13 } /* Literal.String.Regex */ .mw-highlight > pre .s1 { color: #ed9d13 } /* Literal.String.Single */ .mw-highlight > pre .ss { color: #ed9d13 } /* Literal.String.Symbol */ .mw-highlight > pre .bp { color: #24909d } /* Name.Builtin.Pseudo */ .mw-highlight > pre .fm { color: #447fcf } /* Name.Function.Magic */ .mw-highlight > pre .vc { color: #40ffff } /* Name.Variable.Class */ .mw-highlight > pre .vg { color: #40ffff } /* Name.Variable.Global */ .mw-highlight > pre .vi { color: #40ffff } /* Name.Variable.Instance */ .mw-highlight > pre .vm { color: #40ffff } /* Name.Variable.Magic */ .mw-highlight > pre .il { color: #3677a9 } /* Literal.Number.Integer.Long */

(Yes, I also need to do the light-on-dark thing here in this blog)

To get a list of available styles:

$ ./extensions/SyntaxHighlight_GeSHi/pygments/pygmentize -L styles Pygments version 2.2.0, (c) 2006-2017 by Georg Brandl. Styles: ~~~~~~~ * manni: A colorful style, inspired by the terminal highlighting style. * igor: Pygments version of the official colors for Igor Pro procedures. * lovelace: The style used in Lovelace interactive learning environment. Tries to avoid the "angry fruit salad" effect with desaturated and dim colours. * xcode: Style similar to the Xcode default colouring theme. * vim: Styles somewhat like vim 7.0 * autumn: A colorful style, inspired by the terminal highlighting style. * abap: * vs: * rrt: Minimalistic "rrt" theme, based on Zap and Emacs defaults. * native: Pygments version of the "native" vim theme. * perldoc: Style similar to the style used in the perldoc code blocks. * borland: Style similar to the style used in the borland IDEs. * arduino: The Arduino® language style. This style is designed to highlight the Arduino source code, so exepect the best results with it. * tango: The Crunchy default Style inspired from the color palette from the Tango Icon Theme Guidelines. * emacs: The default style (inspired by Emacs 22). * friendly: A modern style based on the VIM pyte theme. * monokai: This style mimics the Monokai color scheme. * paraiso-dark: * colorful: A colorful style, inspired by CodeRay. * murphy: Murphy's style from CodeRay. * bw: * pastie: Style similar to the pastie default style. * rainbow_dash: A bright and colorful syntax highlighting theme. * algol_nu: * paraiso-light: * trac: Port of the default trac highlighter design. * default: The default style (inspired by Emacs 22). * algol: * fruity: Pygments version of the "native" vim theme.

Although you may find it easier looking at the Pygments style gallery.

Categories: LUG Community Blogs

Andy Smith: Let’s Encrypt wildcard certificates, acme.sh and automated DNS verification

Mon, 19/03/2018 - 11:59
Let’s Encrypt’s wildcard certificates

Now that Let’s Encrypt can issue wildcard TLS certificates I found some time to look into that.

I already use a Lua script with haproxy which takes care of automatically answering http-01 ACME challenges, but to issue/renew a wildcard certificate you need to answer a dns-01 challenge. A different client/setup would be needed.

dns-01 ACME challenges

Most of the clients that support ACME v2 offer a range of integrations for DNS providers, plus a manual mode that prints out the DNS record that you need to add and then waits for you to indicate that you’ve done it. I run my own DNS infrastructure so the thing to do would be RFC2136 dynamic DNS updates.

One wrinkle here is that currently none of my DNS zones have dynamic updates enabled. At the moment I manage them as zone files (some are automatically generated by scripts though). After looking at a few of the client options I found that acme.sh supports an “alias zone”.

Basically, in your main zone you create a CNAME for the challenge record that points at another zone, and then enable dynamic updates in that other zone. The other zone is dedicated for this purpose, so the only updates which will be happening will be for the purpose of answering dns-01 ACME challenges. I made my dynamic zone a sub-zone of my main one:

strugglers.net zone file content

These records need to be added to the main zone for this to work.

. . . ; sub-zone purely used for dns-01 ACME challenges. acmesh NS a.authns.bitfolk.co.uk. NS b.authns.bitfolk.com. NS c.authns.bitfolk.com. ; Alias the dns-01 challenge record into the dedicated zone. _acme-challenge CNAME _acme-challenge.acmesh.strugglers.net. . . . acmesh.strugglers.net zone file content

Initially this just needs to be an empty zone with only SOA and NS records, so this is the entire content of the file.

$ORIGIN . $TTL 86400 ; 1 day acmesh.strugglers.net IN SOA a.authns.bitfolk.co.uk. hostmaster.bitfolk.com. ( 2018031905 ; serial 14400 ; refresh (4 hours) 7200 ; retry (2 hours) 1209600 ; expire (2 weeks) 43200 ; minimum (12 hours) ) NS a.authns.bitfolk.co.uk. NS b.authns.bitfolk.com. NS c.authns.bitfolk.com. DNS server configuration

The DNS server needs to know a key by which it will authenticate acme.sh‘s updates, and also needs to be told that the new zone is a dynamic zone. I use BIND, so it goes as follows.

Generate a key for dynamic DNS updates

Use the dnssec-keygen command to generate a key suitable for authenticating DNS updates.

$ dnssec-keygen -r /dev/urandom -a HMAC-SHA512 -b 512 -n HOST DDNS_UPDATE

This creates two files named like Kddns_update.+165+14059.key and Kddns_update.+165+14059.private.

Put the key in the BIND config

Look in the private file and take the key from the line that starts “Key:”. Put that in some config file that you will load into your BIND like this:

key "strugglers" { algorithm hmac-sha512; secret "Sb8nvwpO8bhiU4haPB+NiJKoMO6vVJumrr29Bj3daSuB8hBoTKoqPKMBKTYLRUv12pbKPwJATgdsU6BtL4Hmcw=="; };

The thing in quotes after “key” is a symbolic name for this key and can be anything that makes sense to you. The “secret” is the key from the private file. You can delete the two Kddns_update.+165+14059.* files now.

Put the new zone into the BIND config

The config for the zone itself looks something like this:

zone "acmesh.strugglers.net" { type master; file "/path/to/acmesh.strugglers.net"; allow-update { key "strugglers"; }; }; Reload the DNS server

Once BIND has been reloaded the log file should indicate that the acemsh.strugglers.net zone was loaded correctly, and in my case that triggers DNS NOTIFY to my secondary servers which automatically begin zone transfers.

Check things out with nsupdate

At this point it might be worth using the nsupdate command to check that you can do dynamic DNS updates.

Just type the nsupdate line in the shell, the > is a prompt at which you will type the updates you wish to send. We’ll add a trivial TXT record. The -k argument is the path to the file containing the key.

$ nsupdate -k /path/to/strugglers.key -v > server a.authns.bitfolk.co.uk > debug yes > zone acmesh.strugglers.net. > update add foo.acmesh.strugglers.net. 86400 TXT "bar" > show Outgoing update query: ;; ->>HEADER- opcode: UPDATE, status: NOERROR, id: 0 ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0 ;; ZONE SECTION: ;acmesh.strugglers.net. IN SOA ;; UPDATE SECTION: foo.acmesh.strugglers.net. 86400 IN TXT "bar" > send Sending update to 85.119.80.222#53 Outgoing update query: ;; ->>HEADER- opcode: UPDATE, status: NOERROR, id: 19987 ;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 1 ;; ZONE SECTION: ;acmesh.strugglers.net. IN SOA ;; UPDATE SECTION: foo.acmesh.strugglers.net. 86400 IN TXT "bar" ;; TSIG PSEUDOSECTION: strugglers. 0 ANY TSIG hmac-sha512. 1521454639 300 64 dPndp1/ZyqzmSEn0AKIsGR62HrsplJBhntWioM4oBdPlNXUIAwg7Jwpg DGSM2S3kY+5hfGTleNqwXZrMvnBhUQ== 19987 NOERROR 0 Reply from update query: ;; ->>HEADER- opcode: UPDATE, status: NOERROR, id: 19987 ;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1 ;; ZONE SECTION: ;acmesh.strugglers.net. IN SOA ;; TSIG PSEUDOSECTION: strugglers. 0 ANY TSIG hmac-sha512. 1521454639 300 64 NfH/78kvq6f+59RXnyJwC6kfFRLGjG6Rh9jdYRId7UjH0jwIbtRVpqCu xx4HToGmlJrDTUqpgbYZq2orUOZlkQ== 19987 NOERROR 0 > [Ctrl-D]

And to verify it really got added (though the status of NOERROR should be confirmation enough):

$ dig +short -t txt foo.acmesh.strugglers.net "bar"

That it; you can do dynamic DNS updates.

acme.sh

I’m going to assume you’ve installed acme.sh according to one of its supported installation methods. Personally I am not into curl | sh so I:

  • Create a system user that can’t log in.
  • git clone the source.
  • acme.sh --install it as that user.

acme.sh doesn’t have to be run on the primary DNS server, because it’s going to use a dynamic DNS update to do all the DNS things. It just needs access to the dynamic DNS update key file. Either you can install acme.sh on each host that will need to generate/renew certificates and copy the DNS key there, or else do all the certificate generation/renewal in one place and copy the certificate files around.

However you manage it, make sure that the user you’re going to run acme.sh as can read the dynamic DNS update key file.

Issuing the first wildcard certificate

The first time you issue the certificate you need to set NSUPDATE_KEY and NSUPDATE_SERVER in your environment. After the first successful issuance acme.sh will store these variables in its configuration for use in the automated renewals.

$ NSUPDATE_SERVER=a.authns.bitfolk.co.uk NSUPDATE_KEY=/path/to/strugglers.key ./acme.sh --issue -d strugglers.net -d '*.strugglers.net' --challenge-alias acmesh.strugglers.net --dns dns_nsupdate [Mon 19 Mar 09:19:00 UTC 2018] Multi domain='DNS:strugglers.net,DNS:*.strugglers.net' [Mon 19 Mar 09:19:00 UTC 2018] Getting domain auth token for each domain [Mon 19 Mar 09:19:03 UTC 2018] Getting webroot for domain='strugglers.net' [Mon 19 Mar 09:19:03 UTC 2018] Getting webroot for domain='*.strugglers.net' [Mon 19 Mar 09:19:04 UTC 2018] Found domain api file: /path/to/acmesh/dnsapi/dns_nsupdate.sh [Mon 19 Mar 09:19:04 UTC 2018] adding _acme-challenge.acmesh.strugglers.net. 60 in txt "WmenhbXRtenhpNLYLOBjznyHcVvFk-jjxurCVTrhWc8" [Mon 19 Mar 09:19:04 UTC 2018] Found domain api file: /path/to/acmesh/dnsapi/dns_nsupdate.sh [Mon 19 Mar 09:19:04 UTC 2018] adding _acme-challenge.acmesh.strugglers.net. 60 in txt "fwZPUBHijOQkJJaoOF_nIn3Z_FtuVU9R635NDVz_hPA" [Mon 19 Mar 09:19:04 UTC 2018] Sleep 120 seconds for the txt records to take effect

At this point a DNS update has been crafted and sent so you should see your zone update and zone transfer happen to any secondary servers. If that doesn’t happen within 120 seconds then when Let’s Encrypt tries to verify the challenge it might query a DNS server that doesn’t yet have the record. Your zone transfers need to be reliable.

[Mon 19 Mar 09:21:08 UTC 2018] Verifying:strugglers.net [Mon 19 Mar 09:21:12 UTC 2018] Success [Mon 19 Mar 09:21:12 UTC 2018] Verifying:*.strugglers.net [Mon 19 Mar 09:21:15 UTC 2018] Success [Mon 19 Mar 09:21:15 UTC 2018] Removing DNS records. [Mon 19 Mar 09:21:15 UTC 2018] removing _acme-challenge.acmesh.strugglers.net. txt [Mon 19 Mar 09:21:16 UTC 2018] removing _acme-challenge.acmesh.strugglers.net. txt [Mon 19 Mar 09:21:16 UTC 2018] Verify finished, start to sign. [Mon 19 Mar 09:21:18 UTC 2018] Cert success. -----BEGIN CERTIFICATE----- MIIFETCCA/mgAwIBAgISAz4ZQV27n1FgemVAEhIqiUZnMA0GCSqGSIb3DQEBCwUA MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD . . . NeAmr5I= -----END CERTIFICATE----- [Mon 19 Mar 09:21:18 UTC 2018] Your cert is in /path/to/acmesh/.acme.sh/strugglers.net/strugglers.net.cer [Mon 19 Mar 09:21:18 UTC 2018] Your cert key is in /path/to/acmesh/.acme.sh/strugglers.net/strugglers.net.key [Mon 19 Mar 09:21:18 UTC 2018] The intermediate CA cert is in /path/to/acmesh/.acme.sh/strugglers.net/ca.cer [Mon 19 Mar 09:21:18 UTC 2018] And the full chain certs is there: /path/to/acmesh/.acme.sh/strugglers.net/fullchain.cer Examining a certificate

Just for peace of mind…

$ openssl x509 -text -noout -certopt no_subject,no_header,no_version,no_serial,no_signame,no_subject,no_issuer,no_pubkey,no_sigdump,no_aux -in /path/to/acmesh/.acme.sh/strugglers.net/strugglers.net.cer Validity Not Before: Mar 19 08:21:17 2018 GMT Not After : Jun 17 08:21:17 2018 GMT X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 Basic Constraints: critical CA:FALSE X509v3 Subject Key Identifier: BF:C7:8E:F5:87:05:D0:6E:15:AC:7B:37:9F:82:05:C3:E3:11:B7:32 X509v3 Authority Key Identifier: keyid:A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1 Authority Information Access: OCSP - URI:http://ocsp.int-x3.letsencrypt.org CA Issuers - URI:http://cert.int-x3.letsencrypt.org/ X509v3 Subject Alternative Name: DNS:*.strugglers.net, DNS:strugglers.net X509v3 Certificate Policies: Policy: 2.23.140.1.2.1 Policy: 1.3.6.1.4.1.44947.1.1.1 CPS: http://cps.letsencrypt.org User Notice: Explicit Text: This Certificate may only be relied upon by Relying Parties and only in accordance with the Certificate Policy found at https://letsencrypt.org/repository/

From the Subject Alternative Name we can see it is a wildcard certificate.

Categories: LUG Community Blogs