When using a tool like https://dkimvalidator.com/ to verify configuration of DKIM, SPF, DMARC, etc. for sending mail from a web server, I get a warning like this:
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
It seems like a bad signal even though the score isn't really affected. How do I get rid of it?
The certbot command provides two hooks that run after automated renewals, from the docs:
--post-hook POST_HOOK Command to be run in a shell after attempting to obtain/renew certificates. Can be used to deploy renewed certificates, or to restart any servers that were stopped by --pre-hook. This is only run if an attempt was made to obtain/renew a certificate. If multiple renewed certificates have identical post- hooks, only one will be run. (default: None) --deploy-hook DEPLOY_HOOK Command to be run in a shell once for each successfully issued certificate. For this command, the shell variable $RENEWED_LINEAGE will point to the config live subdirectory (for example, "/etc/letsencrypt/live/example.com") containing the new certificates and keys; the shell variable $RENEWED_DOMAINS will contain a space-delimited list of renewed certificate domains (for example, "example.com www.example.com" (default: None)
This issue is outlined in this (now closed) LE thread and is basically about minimising interruption to services. POST_HOOK executes every time an attempt to renew is made even if no certificates were issued, though only once. This makes it possible to unnecessarily restart services. DEPLOY_HOOK runs for each and every successful certificate renewal. If one uses DEPLOY_HOOK, and has multiple certificates, each service may restart multiple times when once is enough. More info on renewal hooks here.
I use an issuance method that does not interrupt my services at all, e.g.:
certbot certonly --webroot ...
or
certbot certonly --dns-PROVIDER ...
I want to restart/reload each dependent service only once, and only if its certificate actually changed.
I've rebooted the server multiple times for kernel updates, but the microcode doesn't update. I've tried manually initiating it with echo 1 > /sys/devices/system/cpu/microcode/reload, etc. steps.
needrestart keeps telling me
The currently running processor microcode revision is 0xb4 which is not the expected microcode revision 0xb8.
dmesg says
[ 0.000000] microcode: microcode updated early to revision 0xb4, date = 2019-04-01
[ 4.287003] microcode: sig=0x906e9, pf=0x2, revision=0xb4
[ 4.323918] microcode: Microcode Update Driver: v2.2.
(There are no other messages before that first one in unfiltered dmesg output, so no clues as to why it's loading an old one.)
apt list --all-versions intel-microcode says
intel-microcode/bionic-updates,bionic-security,now 3.20190618.0ubuntu0.18.04.1 amd64 [installed]
intel-microcode/bionic 3.20180312.0~ubuntu18.04.1 amd64
None of the manual upgrade steps showed an error, so I'm guessing that if there is one, it's written somewhere else at boot time.
Results of iucode-tool showing both 0xb4 and 0xb8, but also 0xae (which was absent from any prior messages):
selected microcodes:
031/001: sig 0x000906e9, pf_mask 0x2a, 2019-04-01, rev 0x00b4, size 99328
073/001: sig 0x000906ea, pf_mask 0x22, 2019-04-01, rev 0x00b4, size 98304
001/001: sig 0x000906eb, pf_mask 0x02, 2019-04-01, rev 0x00b4, size 99328
048/001: sig 0x000906ec, pf_mask 0x22, 2019-02-14, rev 0x00ae, size 98304
024/001: sig 0x000906ed, pf_mask 0x22, 2019-03-17, rev 0x00b8, size 97280
I'm running a DNS server on a LAN because I don't want an external point of failure for resolution of a bunch of private subdomains, which don't need to be listed in public DNS, anyway.
I have one view set up that resolves our domain or otherwise forwards to our ISP's DNS servers.
It normally works without issue, but currently cannot reach any .co domain unless dnssec is disabled, and I take it I shouldn't do that.
I updated /etc/bind/bind.keys.
How do I debug the cause of the failure? To me it just looks like the RRSIG record has dodgy NS data, or there's some other network failure with the nsX.cctld.co servers, but I don't know nearly enough to resolve it.
# rndc validation check
DNSSEC validation is enabled (view privateservers)
# dig +trace do.co
; <<>> DiG 9.10.3-P4-Ubuntu <<>> +trace do.co
;; global options: +cmd
. 77153 IN NS g.root-servers.net.
. 77153 IN NS a.root-servers.net.
. 77153 IN NS m.root-servers.net.
. 77153 IN NS h.root-servers.net.
. 77153 IN NS k.root-servers.net.
. 77153 IN NS j.root-servers.net.
. 77153 IN NS c.root-servers.net.
. 77153 IN NS b.root-servers.net.
. 77153 IN NS f.root-servers.net.
. 77153 IN NS d.root-servers.net.
. 77153 IN NS e.root-servers.net.
. 77153 IN NS l.root-servers.net.
. 77153 IN NS i.root-servers.net.
;; Received 239 bytes from 192.168.20.1#53(192.168.20.1) in 1 ms
co. 172800 IN NS ns1.cctld.co.
co. 172800 IN NS ns2.cctld.co.
co. 172800 IN NS ns3.cctld.co.
co. 172800 IN NS ns4.cctld.co.
co. 172800 IN NS ns5.cctld.co.
co. 172800 IN NS ns6.cctld.co.
co. 86400 IN DS 21754 8 2 C30634014C0752DA93B0633ED4CE641B63826A5DED820027F4117CA0 C32050A0
co. 86400 IN DS 21754 8 1 8B9B8FDA21B4CF6FC3E97A31FC0D77C1CB7E70EE
co. 86400 IN DS 10384 8 1 DF157833AAD57F3561F3A47F178BA46E7E7183DC
co. 86400 IN DS 10384 8 2 A76358B4C22E95C2C4A56DB8ADC923779E0829142D7C51B04E54769C 86407D70
co. 86400 IN RRSIG DS 8 1 86400 20170826170000 20170813160000 15768 . N8hBVmcw3geU/EqNR2fqWH2rd9v5cdGfZ44h5sxPmreta1SZPupsq3RV FN37fZfKuzcwN7Obe3eE6k3Mxn0KyzGY/cF4wnqCD7HWBrvfz50b1yxD REitHlhKt6ZqC/NPaa5NGa6tWyeKuhD/D3tc74rK95eVnfCWmTY1PFth QoB8IZJFw2UIO8bS9Zpd82im1wHP9PRRF8nWUFYd4rOI6LU6ahCsckij HngqmuLFvfsZeRXY/yAzImy1REbSqAon/RGCsckoeuXs4rLBq7QUxLeA W2GcmczUkxspQciGsK71WgFrRyl2o6NrvlsmTO9XHQ2OVccSp8Ee29FY ukm6wA==
couldn't get address for 'ns1.cctld.co': failure
couldn't get address for 'ns2.cctld.co': failure
couldn't get address for 'ns3.cctld.co': failure
couldn't get address for 'ns4.cctld.co': failure
couldn't get address for 'ns5.cctld.co': failure
couldn't get address for 'ns6.cctld.co': failure
dig: couldn't get address for 'ns1.cctld.co': no more
Then I disable validation and I get this:
# rndc validation off
# dig +trace do.co
; <<>> DiG 9.10.3-P4-Ubuntu <<>> +trace do.co
;; global options: +cmd
. 84407 IN NS m.root-servers.net.
. 84407 IN NS g.root-servers.net.
. 84407 IN NS a.root-servers.net.
. 84407 IN NS k.root-servers.net.
. 84407 IN NS i.root-servers.net.
. 84407 IN NS b.root-servers.net.
. 84407 IN NS l.root-servers.net.
. 84407 IN NS f.root-servers.net.
. 84407 IN NS d.root-servers.net.
. 84407 IN NS j.root-servers.net.
. 84407 IN NS c.root-servers.net.
. 84407 IN NS h.root-servers.net.
. 84407 IN NS e.root-servers.net.
;; Received 239 bytes from 192.168.20.1#53(192.168.20.1) in 1 ms
co. 172800 IN NS ns1.cctld.co.
co. 172800 IN NS ns2.cctld.co.
co. 172800 IN NS ns3.cctld.co.
co. 172800 IN NS ns4.cctld.co.
co. 172800 IN NS ns5.cctld.co.
co. 172800 IN NS ns6.cctld.co.
co. 86400 IN DS 10384 8 1 DF157833AAD57F3561F3A47F178BA46E7E7183DC
co. 86400 IN DS 10384 8 2 A76358B4C22E95C2C4A56DB8ADC923779E0829142D7C51B04E54769C 86407D70
co. 86400 IN DS 21754 8 1 8B9B8FDA21B4CF6FC3E97A31FC0D77C1CB7E70EE
co. 86400 IN DS 21754 8 2 C30634014C0752DA93B0633ED4CE641B63826A5DED820027F4117CA0 C32050A0
co. 86400 IN RRSIG DS 8 1 86400 20170826170000 20170813160000 15768 . N8hBVmcw3geU/EqNR2fqWH2rd9v5cdGfZ44h5sxPmreta1SZPupsq3RV FN37fZfKuzcwN7Obe3eE6k3Mxn0KyzGY/cF4wnqCD7HWBrvfz50b1yxD REitHlhKt6ZqC/NPaa5NGa6tWyeKuhD/D3tc74rK95eVnfCWmTY1PFth QoB8IZJFw2UIO8bS9Zpd82im1wHP9PRRF8nWUFYd4rOI6LU6ahCsckij HngqmuLFvfsZeRXY/yAzImy1REbSqAon/RGCsckoeuXs4rLBq7QUxLeA W2GcmczUkxspQciGsK71WgFrRyl2o6NrvlsmTO9XHQ2OVccSp8Ee29FY ukm6wA==
;; Received 867 bytes from 192.5.5.241#53(f.root-servers.net) in 19 ms
do.co. 7200 IN NS walt.ns.cloudflare.com.
do.co. 7200 IN NS kim.ns.cloudflare.com.
131vnuv1malje6dnud9fsaqdrqcs5i91.co. 86400 IN NSEC3 1 1 1 F873A2F5 1356V3361NJ2BQROG5HKD76E66S04L02 NS SOA RRSIG DNSKEY NSEC3PARAM
131vnuv1malje6dnud9fsaqdrqcs5i91.co. 86400 IN RRSIG NSEC3 8 2 86400 20170821234143 20170722233946 63993 co. E8Sg+iSMx1zSNIfC7eDVbBE+TSIg4W58SDPqwXA04EjPlpdubb7cakdv bvwdjBdWpyb+No7SLByqKNnQN7BsYvvdmLsDpbAEGcQ+agXmUwImddDa 9J/2VkOiNkiKYgI174elEuitoWhQH6PVSwO6Nb1nBl4o9em0v9zGhbYA 2Jy6VLKWNYL6bh9CNSGJsl4NthISx9nBZKwBQ7vNnZ/mrQ==
pte00qfgi7b6087qivojmk9kqr2u6gka.co. 86400 IN NSEC3 1 1 1 F873A2F5 PTRFFSEIBU5MCNK4CRV8JFRTQ7QB3I0G NS DS RRSIG
pte00qfgi7b6087qivojmk9kqr2u6gka.co. 86400 IN RRSIG NSEC3 8 2 86400 20170827152341 20170728142341 63993 co. hSH7UQuVYYdfZdKjh8q98boxNOVaE/j8DlWVHcWT17Q3Zb5+m7xDJRQ9 42KaaIla3rZ6e7RYy1qXWh+6VFB5KRxv9ec2RAuYPNB/9XJe2IdlnsE4 t1IqGFo+O4ZY5mlj+QxMcLrx3FlM9ZzSzat9SlS6sSxv7w+0s/yuIMqv 3ZjXqjHYdDgshA+g71QjoSqS3jz0a/muAiznNfuc+Qclcw==
;; Received 643 bytes from 156.154.101.25#53(ns2.cctld.co) in 229 ms
do.co. 300 IN A 67.199.248.13
do.co. 300 IN A 67.199.248.12
;; Received 66 bytes from 173.245.59.148#53(walt.ns.cloudflare.com) in 27 ms
Someone managed to delete (instead of deallocate) a VM from our portal.azure.com account. It's apparently quite a quick and unceremonious process.
The .vhd still exists and I have a rough idea of the grade of VM it was. It seems that 99% of the instructions out there make it look very easy but are for the old manage.windowsazure.com site, which does not seem to apply. This is not a classic VM and it's storage is not even visible in the old manager.
I have both the cross platform command line tools and the azure cmdlets for powershell installed, but do not know what command to use, let alone what parameters to set.
localhost:25 to our.isps.mail.server:25.
I know that Apache must use UNC paths for network resources when run as a service, but I have a local drive I:. It's not virtual drive, nor a mapped drive, it's a single physical disk inside the case. I keep getting this error in my logs
Syntax error on line X of C:/Program Files/Apache Software Foundation/Apache2.2/conf/extra/httpd-vhosts.conf:
<Directory "I:/path/to/web/root"> path is invalid.
However that path definitely exists. I can access it through a different UNC share, but then wouldn't every file access have go through SMB? Wouldn't this kill performance?