xrogaan | gnarface: so this is the crypto thing that is failing on boot, sometimes https://dpaste.com/FHYR6C5SR | 02:10 |
---|---|---|
xrogaan | probably benign: https://serverfault.com/questions/746733/luks-error-during-boot | 02:33 |
xrogaan | /proc/crypto reports drbg_pr_ctr_aes128 self test as "unknown". | 02:35 |
gnarface | xrogaan: i probably don't know about it but /msg it to me | 02:53 |
gnarface | or is it just the two repeating lines from that post? | 03:00 |
gnarface | oh hmm, i guess they're unique | 03:00 |
gnarface | yea i dunno though | 03:00 |
gnarface | did you try the solution listed there? | 03:13 |
xrogaan | Given the first answer, I don't think it's an issue. | 05:28 |
xrogaan | gnarface: I linked the dpaste, it's the kernel error. | 05:28 |
dokma | Trying to parse this failing command: test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))' && certbot -q renew | 10:44 |
dokma | The systemd chunk is not going to work obviously. | 10:44 |
dokma | What is that exclam doing? | 10:45 |
rrq | not | 10:46 |
dokma | So /usr/bin/certbot must exist and /run/systemd/system must not be a directory ? | 10:47 |
dokma | And then run perl -e 'sleep int(rand(43200))' && certbot -q renew | 10:48 |
dokma | What's the point of the sleeping part? | 10:48 |
rrq | that'd be the test, yes. not something one need to test more than once in a lifetime though... | 10:48 |
dokma | It's a cron command that is supposed to renew my certs. | 10:48 |
dokma | So I basically just need to run certbot -q renew | 10:48 |
dokma | since the folder does not exist and /usr/bin/certbot is an executable | 10:49 |
rrq | yes; you can remove the test bit once you've verified it; it's not going to change is it? | 10:49 |
dokma | That sleep part I don't get. | 10:49 |
dokma | Why the huge wait? | 10:49 |
rkta | it's a random wait period | 10:50 |
rrq | I think that's the packager trying to avoid the server getting lots of requests at the same time... | 10:50 |
dokma | rkta: I did get that. I did not get why is it used. | 10:50 |
dokma | Ohhh... I guess that does make sense | 10:50 |
rrq | you can change that into your desired once-in-a-liftime random choice as well | 10:51 |
rkta | yes, that it one thing which comes builtin with systemd. Looks like that is their version w/o systemd | 10:51 |
dokma | That is not the problem. certbot is spitting out: Failed to renew certificate smtp.evorion.hr with error: Problem binding to port 80: Could not bind to IPv4 or IPv6. | 10:55 |
dokma | So I'm trying to figure out how to do the automatic verification properly. | 10:55 |
dokma | Oh, I just needed to stop apache2. | 10:57 |
dokma | This worked just fine: /etc/init.d/apache2 stop; certbot -q renew; /etc/init.d/apache2 start | 10:57 |
rwp | So apparently you have certbot configured to be its own http port 80 web server and apache is already running. | 10:58 |
rwp | That's one of the possible configurations. But I dislike it. Because one must stop apache around it. That's hokey to me. | 10:58 |
rwp | The other way to configure things is to configure apache to serve the .well-known ACME Let's Encrypt challenge and then there is no need for certbot to self host it. | 10:59 |
rwp | IMHO too certbot is hard to use because it keeps a binary database of its own configuration. One gives it commands and it changes its binary configuration file. | 11:00 |
rwp | That random sleep is to stop the https://en.wikipedia.org/wiki/Thundering_herd_problem | 11:01 |
rwp | So that across the world all servers wanting to renew don't all trigger at once. | 11:01 |
rwp | But that random 0-43200 second delay seems much longer than needed to me. But I guess it all depends upon when the cronjob is configured to run. | 11:02 |
rwp | Depending upon how certbot was installed it probably came with an apache configuration snippet to serve the .well-known directory itself. | 11:04 |
rwp | Meaning that having configured certbot to http port 80 serve those files is probably not needed. | 11:04 |
dokma | rwp: Awesome info. Perfectly clear. Will check if apache2 has any config to host .well-known | 11:08 |
dokma | rwp: hmmm... aparently, all domains have the .well-known already configured. | 11:09 |
dokma | smtp.evorion.hr was my mail host so it did not have HTTP config. | 11:09 |
rwp | Right. It will be a shared config, shared for all VirtualHost domains. | 11:09 |
dokma | I can't even remember why I used that domain. | 11:09 |
rwp | I used to use certbot some time ago. But got so annoyed at it dragging in its own virtual python environment for a total of about 50MB that I switched away from it. | 11:10 |
rwp | I am not using the dehydrated client. It's a small simple shell script! apt-cache show dehydrated | 11:11 |
dokma | never heard of it. | 11:11 |
rwp | However the packager created a bug when creating the package making it a little tricky to configure. | 11:11 |
rwp | So honestly it might be easier to install the upstream direct from github. Since it is one single shell script it is easy. But then updates are on you to keep up with. | 11:12 |
dokma | I prefer simpler things. That's why I detest systemd. | 11:12 |
rwp | The packager of dehydrated got confused between .well-known/acme-challenge and .well-known/acme-challenges singular and plural! | 11:13 |
rwp | Which means that one must fix that bug to use it. I override it in the local config part. But gosh that's a shame about that confusion. | 11:13 |
rwp | Of course the upstream doesn't have that confusion so a straight simple install avoids it. (shrug) | 11:14 |
dokma | I don't have the time to try it now as we are overloaded atm. | 11:14 |
dokma | Will be for the next 2 months so it will have to wait. | 11:15 |
rwp | Sure. Time and life is what keeps everything from happening all at once. | 11:15 |
dokma | rwp: do you perchance know if letsencrypt certs are wildcards? | 11:16 |
rwp | Not by default. They did not support wild cards at all for a long time. But then in recent times, not sure how long, they now support wild card certs. | 11:17 |
rwp | I stopped using certbot by then. So I don't know how to drive certbot to do it. Just that it now supports it. | 11:17 |
dokma | Thanks a bunch! Gotta keep moving. | 11:17 |
rwp | https://certbot.eff.org/ Which includes a recipe generator which is pretty clever. | 11:18 |
dokma | Thanks! I'm gone. | 11:19 |
devuan | how to cat a file after a pipe. For example, this command list the newest files in a dir, and show it. Then how to cat it ? | 13:16 |
devuan | ls -Art | tail -n 1|cat (the file that is shown), I recall there is a symbol for taking the value of the previous pipe | 13:16 |
onefang | tee might be useful. | 13:17 |
devuan | onefang, how exactly to use tee for such a purpose | 13:21 |
joerg | devuan: you want to cat the file that the name of is being printed by ls? | 13:45 |
joerg | cat $(ls -Art | tail -n 1) | 13:45 |
joerg | or | 13:45 |
joerg | cat $`ls -Art | tail -n 1` | 13:45 |
joerg | cat `ls -Art | tail -n 1` ;# sorry typo | 13:46 |
_jay_ | devuan: alternative approach; prefix the lines with filename: grep -H '.*' "$(ls -Art | tail -n 1)" | 13:50 |
_jay_ | using tee you could print the filename first by using stderr: cat "$(ls -Art ./*.*| tail -n 1 | tee /dev/stderr)" 2>&1 | 13:52 |
joerg | hah, that's tricky | 13:53 |
_jay_ | joerg: you could also make your shell echo commands to see what's file is passed to cat, but it will be more noisy: set -x; cat "$(ls -Art| tail -n 1)"; set +x | 13:55 |
joerg | sorry, no malice assumed, but it feels sort of cheating when a user picks "devuan" for nickname | 13:55 |
_jay_ | heh | 13:57 |
joerg | _jay_: I know :-) actually I did exactly that yesterday https://termbin.com/z0hcw but it's _very_ debugging and non-intuitive and clumsy | 13:58 |
phogg | this is the safe way to work on the newest file in the dir: find . -maxdepth 1 -type f -printf '%T@/%p\0' | sort -zrn | while IFS=/ read -rd '' _ file; do cat "file"; break; done | 13:58 |
phogg | er, cat "$file" I mean | 13:58 |
joerg | hmm find is nice and all, but cat $(ls --sort=t --reverse --width=1 --almost-all | tail -n1) seems usually fine | 14:17 |
phogg | it's not safe unless you use modern GNU ls and set --quoting-style=shell (or another safe value) | 14:19 |
phogg | honestly a lot of pain and frustration could have been saved if the standards people in the 80s/90s had standardized ls --quoting-style | 14:19 |
phogg | but alas it did not exist then | 14:20 |
joerg | depending on which of the 3 timestamps of a file you want, you may add a -c for c(reation)time instead of m(odification)time | 14:20 |
phogg | you would have to change the -printf string if you wanted to alter that, too | 14:21 |
joerg | or I give you that | 14:21 |
joerg | cat "$(ls --sort=t --reverse --width=1 --almost-all | tail -n1)" is much safer | 14:22 |
joerg | ok, even | 14:23 |
joerg | mich safer than without the ticks | 14:23 |
phogg | again, --quoting-style=shell is needed | 14:23 |
sixwheeledbeast | parsing anything with ls is asking for pain. its for human reading only. | 14:25 |
sixwheeledbeast | find solution is nice | 14:25 |
phogg | sixwheeledbeast: without --quoting style yes, with --quoting-style it can be fine. The quotes can cause other problems, though, because you have to resolve them in order to have a filename literal. | 14:25 |
* joerg doubts a user who comes here asking what's the difference between parameter substitution and stdin-redirection/piping will understand and benefit from this | 14:25 | |
phogg | but at least you are guaranteed to have parseable bytes. | 14:25 |
phogg | joerg: I am engaged in a hopeless war against the Unix shell cargo cult. The only way to win is to take a hard line against popular but unsafe tropes, and to spread information as widely as possible. | 14:27 |
phogg | do you know how many times I still see [ x"$var" = x ] ? | 14:27 |
joerg | and yes, >><sixwheeledbeast> parsing anything with ls is asking for pain<< is generally absolutely correct | 14:32 |
joerg | then, you could argue "when you want to automatically cat the newest file of a dir, you got problems with the goal you want to achieve, not with the tools you use to achieve it§ | 14:35 |
phogg | definitely that^ | 14:36 |
sixwheeledbeast | dont even start on xy | 14:36 |
joerg | and then there's inotifywait :-) | 16:10 |
joerg | phogg: do you know of a concise table/list that tells which commandline util stdout are "stable" well-defined format and which are completely bogus, messed up by locale/localization etc? | 18:06 |
joerg | and maybe let's take this to #devuan-offtopic | 18:07 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!