If you can, you should use
flock(1) for shell script locking
I have in the past worked out and used complicated but portable approaches for doing locking in shell scripts. These approaches get much more complicated if processes can die abruptly without undoing their lock. You can generally arrange things so that your locks are cleared if the entire machine reboots, but that's about it as far as simple approaches go. Sometimes this is what you want, but often it isn't.
As a result of a series of issues with our traditional shell script
locking, I have been more and more moving to using Linux's
flock(1) when I can,
which is to say for scripts that only have to run on our Linux
machines (which is almost all of our machines today).
sufficiently useful and compelling here that I might actually port
it over to other Unixes if we had to integrate such systems into
our current Linux environment.
(Anything we want to use should have
flock(2), and hopefully that's the only
flock program really depends on.)
There are two strongly appealing sides to
flock. The first is
that it provides basically the usage that we want; in normal
operation, it runs something with the lock held and releases the
lock when the thing exits. The second is that it automatically
releases the lock if something goes wrong, because
evaporate when the file descriptor is closed.
(The manpage's description of '
-o' may make you confused about
flock means is that the open file descriptor of the
lock is not inherited by the command
flock runs. Normally you
want the command to inherit the open file descriptor, because it
means that so long as any process involved is still running, the
lock is held, even if
flock itself gets killed for some reason.)
Generally I want to use '
flock -n', because we mostly use locking
for 'only one of these should ever be running at once'; if the lock
is held, a previous cron job or whatever is still active, so the
current one should just give up.
We have one script using a traditional shell script approach to
locking that I very carefully and painfully revised to be more or
less safe in the face of getting killed abruptly. Since it logs
diagnostics if it detects a stale lock, there's a certain amount
of use in having it around, but I definitely don't want to ever
have to do another script like it, and it's a special case in some
other ways that might make it awkward to use with
experience of revising that script is part of what pushed me very
strongly to using
flock for others.
Getting NetworkManager to probably verify TLS certificates for 802.1x networks
I'll start with my tweets:
We have an 802.1.X WPA2 Enterprise university-wide wireless network, using PEAPv0 authentication, which involves a TLS certificate. I do not appear to be able to get NetworkManager to verify the TLS certificate in a way that will let me actually connect.
The only way I can connect to our university wifi is by setting 'No CA certificate is required'. I cannot supply a CA certificate that works (I've tried), and I cannot turn on 802-1x.system-ca-certs ; nmcli just doesn't save it, no matter what, without any reported error.
With the aid of some replies from @grawity, I was able to navigate to a solution that allows me to connect without that 'No CA certificate is required' having to be set, and probably even verifies the TLS certificate.
The magic trick for me was telling NetworkManager that it should
use the system bundle of TLS certificate as the 'CA certificate'
it wants. The one important trick is that NetworkManager wants the
PEM format certificate bundle (and/or
certificate), not the DER form.
How you tell them apart is that the PEM form is base64 ASCII while
the DER form is binary. Anything with a
.pem extension had better
be a PEM file, but a
.crt extension can be either.
On Fedora 29, the system certificate bundle is found as either /etc/ssl/certs/ca-bundle.crt or /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem; the former is a symlink to the latter. On Ubuntu and Debian, you want /etc/ssl/certs/ca-certificates.crt. I don't know if there are any special SELinux considerations that apply depending on the path you select, because I turned that off long ago on my laptop.
I don't know if this setup makes NetworkManager actually verify the TLS certificates (or perhaps wpa_supplicant, which is apparently the thing that really does the work even when NetworkManager is being the frontend). But at least I'm not telling NetworkManager to maybe ignore TLS security entirely.
(When I was looking at logs through journalctl, they were sufficiently ambiguous to me that I couldn't be sure.)
Sidebar: A further puzzle
At this point I don't have my laptop and its logs of TLS certificate
information handy, but the more I look at our university page for
campus wireless and the certificates it lists, the more puzzled I get.
My attempts to verify the TLS certificate started with the TLS
certificate listed there and proceeded through what '
dump' told me were the CA
certificates for that TLS certificate. However, now that I look
more carefully, the page also has a CA bundle that is supposed to
be current, but that CA bundle has a rather different set of CA
certificates. It's possible that had I gotten and used that CA
bundle, the actual 802.1x TLS certificate I was presented with would
(It's apparently possible to capture the 802.1x server TLS certificate, but it may not be easy. And you have to be on the wireless network in question, which I'm not as I write this entry.)