An earlier post talked about switching my server tarragon (where this blog sits) to a wildcard certificate from letsencrypt. There were two reasons why I was using a wildcard certificate. One had to do with test versions of websites that run on this server, and the need that some of those sites have for wildcards, of the form: bob.websitename.com, sally.websitename.com, etc. The other reason was that I have a lot of hosts (oregano, cinnamon, paprika, lemongrass) in addition to tarragon that “need” to have a certificate, for https, for imap, and for smtp, and when I was having to pay for them, it was cheaper to get one wildcard for wmbuck.net. Continue reading Certificates Redux
I have used dynamic dns for around 20 years, I think. But I have always used dyndns.com which these days seems to want to call themselves dyn.com. And some years back they were bought by Oracle, the kiss of death, and now they are impossible to deal with, arrogant, unsupportive, insular – all the things I expect of Oracle.
And why have I kept using them? Because that is what the routers supported. Dyndns was there first, and the ubiquitous linksys and netgear routers usually have a feature to do automatic updates for dynamic dns, but (often) the router will only update dyndns: nobody else. And I’ve got routers installed in various people houses that are doing this.
But I recently added a new house that I support, and that person has a proprietary and ponderous comcast router, which will barely do anything useful, and has no facility to update dynamic dns.
In an earlier post I related how I had moved to letsencrypt for tarragon. In the process of doing some cleanup of the /etc/letsencypt directory, and my repository, I managed to stupidly get one wrong private key file into the batch of all the https vhosts, such that the http config file for xyz.com specified an SSLCertificateFile and SSLCertificateKeyFile which did not match.
It took me hours and hours to figure this out, because Apache simply fails to start and gives no indication whatever what has pissed him off. I wasn’t too stupid to figure out that I had been messing with the certs yesterday, and the problem might lie there somehow. But I have about 15 vhosts, so it was tedious. In the end I resorted to strace, and saw the problem.
Comodo is after me to renew, offering a free year. The last time I attempted to install a wildcard certificate from Lets Encrypt, shortly after they introduced the feature, I wasn’t able to figure it out. Now, 9 months later, there is a lot more information about how to do it. Before spending the money for a commercial cert, I thought I would give it a try.
I used the following on tarragon:
certbot certonly \
--server https://acme-v02.api.letsencrypt.org/directory \
-d wmbuck.net -d *.wmbuck.net \
It is important that the server url by v02, because v01 servers can’t issue wildcard certs. I had to put TXT records in the DNS for them to verify, and they created the cert into the /etc/letsencrypt/live directory where all the others are.
This was trivially easy. Goodbye Comodo.
I find the whole clamav subsystem to be fragile. I think this is because it is written as a tool which stands on its own, but I’m only using it as a subsystem hung onto the side of amavisd. So there is some hand-waving and jiggery pokery with the sockets and the permissions to enable the two to communicate, which has to be done manually, and is not properly a part of either subsystem.
I have another article on setting up this subsystem here, which records some of the stuff being done. I think basically, amavisd has to know where the shared socket is, in order to send messages to clamav to check, and they have to agree on the ownership and permissions of the socket and its directory.
Once in a while that stuff gets crosswise, and since I only vaguely understood what was going on, and only did the hand-waving by rote, I got annoyed with it. I’ve grown used to being able to just have things slot in and work, without my having to actually dig in and understand them. The nerve of these people, to expect me to know what is going on in order to make it work! Irony intended. Continue reading Clamav and Amavisd
I wanted a way to be able to determine roughly how long it had been since a user had been active. I defined active to mean that the user had had to authenticate onto a system. This is so that a box on which the user had logged in has gone into screen lock, and the user has then authenticated again to the display manager.
I used the audit log of auditd to detect when a user has authenticated to a display manager. Auditd comes installed on Fedora, but I had to install it on the ubuntu boxes. Continue reading Recording last authentication
I have been plagued by this error in subversion particularly when trying to commit from some of the boxes which I use less frequently:
svn: E175002: Unexpected HTTP status 200 ‘OK’ on ‘POST’ request to ‘/svn/!svn/me’
I have spent hours doing searches, reading posts, but have never found anyone whose issue was exactly like mine, not been able to figure it out based on other peoples issues. I resolved today to pay serious attention to figuring it out.
The solution turned out to be related to the url I used when I check something out of the svn repository. Long ago I set up a cname in dns for svn.wmbuck.net, and for a long time I used it. There is an apache config file for the servername svn.wmbuck.net, and it redirects http to https. Then at some point I began to just use https://wmbuck.net/svn/… to check things out. And that is where I went wrong, because that will work fine to do checkout, but when I try to commit from a box with that url (wmbuck.net) the http request is being routed to the default server, and the setup of the SSL session is failing.
I’m unsure exactly what is happening to cause the request to go to the default server. Perhaps the commit request does not specify SNI information.
What I do know is how to fix it. Do the checkout with https://svn.wmbuck.net/svn/
I had some trouble on the development box with permissions and decided it would be “easy” to just have apache run under user dee, that would just make everything so much easier. Right.
Two things have come up so far, and more likely to follow. One, I had to change the ownership on /var/lib/php/session from apache to dee. Second, I had to add dee into tlsusers so the media stuff can read the certificate.
This may have been a bad idea.
1/31/18: Went back to using apache user, when I moved to Fedora 27. Fedora now uses php-fpm service, and now apache needs to open a socket to it, and it just became complicated.
I’ve been using this Samsung 4K screen for 3 years. I never adjusted any of the parameters for making things larger. I just got used to the small fonts, and blew things up by application when I needed to.
I’ve been doing some reading in anticipation of getting a new laptop maybe with hidpi. Learned stuff about changing resolution.
With Gnome-Tweak tool->Windows->HIDPI Window scaling, can blow up everything in Gnome. Can only have integer values, so with 2, I can double the size. But after several years of smaller sizes I don’t really like this. Might need it on the laptop though.
With Firefox and Thunderbird, use config editor and find layout.css.devPixelsPerPx. This can have non integer values and 1.5 in Thunderbird is better for me. For Firefox I currently have it set at 1.3.
Continue reading 4K Screen
I have some problem using mod_xsendfile on tarragon. I’ve been working on getting this working for 2 days. I have had to get into the source code of the apache module to figure it out, and I want to turn on the debugging option to see what is going on.
So I have to recompile the c source file, with the define of _DEBUG, and install the it as a module. Had to figure out how to do this. It is very easy. But easy doesn’t mean I’ll remember it, thus this post.
I cloned the source:
git clone https://github.com/nmaier/mod_xsendfile (into my local git repo), and then cd into the directory, and
apxs -D_DEBUG -i -c mod_xsendfile.c
This creates the module with debugging defined, and puts it in /usr/lib64/httpd/modules/mod_xsendfile.so
It still needs to be loaded into apache. Instructions at his site say to use the -a flag, to activate, but while that would work on a simple site, it tries to put the LoadModule into /etc/httpd/conf/httpd.conf, and all my LoadModule statements are in files in the directory /etc/httpd/conf.modules.d so I need to create /etc/httpd/conf.modules.d/xsendfile.conf containing:
LoadModule xsendfile_module modules/mod_xsendfile.so
The module will log debug statements, but this still won’t actually get you any log records until you set LogLevel debug in the apache config file.
Then restart apache and Bob’s your uncle.