Re: certbot in cron - best way?
On 2/21/24 10:07, Stuart Henderson wrote: You might like to investigate ~ in crontab(5), e.g. "~ 0,12" and lose the "sleep". Wouldn't it be better to have certbot write files into a directory served by httpd so you don't need the "rcctl stop" though? Yes, it would be better. Today had a problem in which rcctl stop worked, but rcctl start didn't. Seems like --webroot from certbot can do the trick. Will test in a few days with an expiring certificate. --fm
Re: Automatic OS updates
Kernels with just "OpenBSD 7.5" will appear for some time before pub/OpenBSD/7.5/*/packages are available. -- Sent from a phone, apologies for poor formatting. On 21 February 2024 20:36:39 Kirill A. Korinsky wrote: On Wed, 21 Feb 2024 21:11:05 +0100, Stuart Henderson wrote: If you're using sysupgrade -s, you also want -Dsnap in pkg_add. After double check in man it seems not nessesary, let me quote: %c Expands to the string "snapshots" when running a -current or -beta kernel, or if the command line option -D snap | -D snapshot is specified. Otherwise, %c expands to %v, which selects a release version. -- wbr, Kirill
Re: Automatic OS updates
Well, in a few weeks you will see why you need it.
Re: Automatic OS updates
On Wed, 21 Feb 2024 21:11:05 +0100, Stuart Henderson wrote: > > If you're using sysupgrade -s, you also want -Dsnap in pkg_add. > After double check in man it seems not nessesary, let me quote: %c Expands to the string "snapshots" when running a -current or -beta kernel, or if the command line option -D snap | -D snapshot is specified. Otherwise, %c expands to %v, which selects a release version. -- wbr, Kirill
Re: Automatic OS updates
On 2024-02-21, b...@fea.st wrote: > FWIW if you guys want to yell at me for spreading bad ideas, > I've posted how to do automatic updates here: > > https://openbsd.pages.dev/auto-updates/ If you're using sysupgrade -s, you also want -Dsnap in pkg_add.
Re: Automatic OS updates
On Wed, 21 Feb 2024 18:05:56 +0100, b...@fea.st wrote: > > FWIW if you guys want to yell at me for spreading bad ideas, > I've posted how to do automatic updates here: > > https://openbsd.pages.dev/auto-updates/ > > I'm both trying out the Hugo package and like, documenting > how I've set things up in case I have to reinstall. > > Time moves fast and I'm damn impressed by how smooth the > BSD experience is. > I suggest to add that regression may occure during an upgrade. And personally, bug fixing a nigth upgrade is not something that I prefer to do with morning coffee. -- wbr, Kirill
Re: Automatic OS updates
FWIW if you guys want to yell at me for spreading bad ideas, I've posted how to do automatic updates here: https://openbsd.pages.dev/auto-updates/ I'm both trying out the Hugo package and like, documenting how I've set things up in case I have to reinstall. Time moves fast and I'm damn impressed by how smooth the BSD experience is.
Re: Block HTTP requests from non-browser clients
Sorry I posted to the wrong thread. Please disregard.
Re: Block HTTP requests from non-browser clients
FWIW if you guys want to yell at me for spreading bad ideas, I've posted how to do automatic updates here: https://openbsd.pages.dev/auto-updates/ I'm both trying out the Hugo package and like, documenting how I've set things up in case I have to reinstall. Time moves fast and I'm damn impressed by how smooth the BSD experience is.
Re: Block HTTP requests from non-browser clients
On 2024/02/21 21:57:29 +0800, Sadeep Madurange wrote: > Hello, > > Is there a way to block non-browser clients from accessing a website > (e.g., scraping attempts by bots or even software like Selenium that > might programmatically control a browser), preferrably before the > requests reach the webserver? > > I'm wondering if there's a to do that with, for example, pf to block > such requests completely rather than responding with a 403. I don't think you could *reliably* do this. You mention Selenium, and that's a "real browser", but also one could use nc(1) and use the same mix of headers that firefox would send. So, there are no practical ways to distinguish the traffic based on the request. (abusers don't usually set the 'evil bit' on the packets :/) What you could do is some kind of clownflare shit which blocks your user behind a page that requires a js challenge to continue. (and that i personally hate.) Or maybe just limit the number of connections you accept from a given ip per time delta (max-src-conn-rate in pf.conf). or maybe something else, since you asking for a solution but not telling your problem :) (which i assumed is stopping the flood of bad requests from bad bots.)
Re: Block HTTP requests from non-browser clients
On Wed, 21 Feb 2024 14:57:29 +0100, Sadeep Madurange wrote: > > Is there a way to block non-browser clients from accessing a website > (e.g., scraping attempts by bots or even software like Selenium that > might programmatically control a browser), preferrably before the > requests reach the webserver? > > I'm wondering if there's a to do that with, for example, pf to block > such requests completely rather than responding with a 403. > Here the whole industry which is called Bot Managment which solves that issue via analyzing request, offers to some edge cases captcha and so on. A trivial bot can be catch by regex against User-Agent, or via rate limit. But more sophisticated ones need a lot of tools, which may include things like crossing user agent with TLS-level extentions inside Hello packet, checks against lists of blacklisted IPs and so on. As far as I know the best public availabe list of "bad IP" is https://www.blocklist.de/ which isn't full but allows to ban automatically something. Thus, you may use spamd-setup in blocking mode to fill pf rules via cron. -- wbr, Kirill
Block HTTP requests from non-browser clients
Hello, Is there a way to block non-browser clients from accessing a website (e.g., scraping attempts by bots or even software like Selenium that might programmatically control a browser), preferrably before the requests reach the webserver? I'm wondering if there's a to do that with, for example, pf to block such requests completely rather than responding with a 403. -- Sadeep Madurange PGP: 103BF9E3E750BF7E
Re: certbot in cron - best way?
On 2024-02-20, Odhiambo Washington wrote: > This should work: > > 0 0,12 * * * /bin/sleep 1552 && rcctl stop httpd && certbot renew && > rcctl start httpd You might like to investigate ~ in crontab(5), e.g. "~ 0,12" and lose the "sleep". Wouldn't it be better to have certbot write files into a directory served by httpd so you don't need the "rcctl stop" though?
Re: Automatic OS updates
On 2024-02-20, obs...@loopw.com wrote: > > >> On Feb 20, 2024, at 2:31 AM, Thomas Schmidt >> wrote: >> >> OP did indeed mean `sysupgrade`, > > which makes little sense _unless_ on -current, which will guarantee to break > this every sixth months when -current shifts about. > >> but fwiw, `syspatch && reboot` reboots >> your system if a patch as applied. I got it in all of my servers' >> cronjobs. > > Most of the patches don’t require a reboot. Correct. Looking at the 7.4 patches, only 3 affect the kernel and definitely need a reboot to get applied: 002_msplit - requires reboot 008_vmm - requires reboot 009_pf - requires reboot Two where you don't really need to do anything other than apply the patch: 003_patch 004_ospfd (because, if you're affected by it, then things would be broken already) The rest don't actually need a reboot, but do need *some* things restarting if you're using them: 001_xserver 005_tmux 006_httpd 007_perl 010_xserver 011_ssh 012_xserver 013_unbound (Also: had there been fixes to libraries - libc, libssl, etc - they would be in this category too - you could figure out which long-running processes would need to be restarted and do that). However, considering the "*some* things need restarting" case, given what is available from syspatch, rebooting is the only reasonable way to automate making sure that anything needing a restart really is restarted. > This idea sounds horrible for uptime. Sorry. I’m not rebooting something > because a font was patched… There is a fairly high bar for a fix to get turned into a syspatch. Now, you might not be affected by every patched bug, and if you're updating manually then you can make that decision. But this thread is about automating, and the majority of syspatches do require processes to be restarted in order to take effect.
Re: Function key in cwmrc
On Mon, Feb 19, 2024 at 8:41 AM Omar Polo wrote: > > On 2024/02/19 07:34:01 +, Ioan Samarul wrote: > > Hello to you all! > > > > Is it possible to define something like - in cwm configuration > > file? The function key combination from my laptop are not recognized > > so I try to create a hack by using a script that does the same thing > > (volume/brightness up/down). > > Not exactly, fn is not a modifier key for what Xorg can see, unlike > shift/ctrl/mod1/... (AFAIK) > > What you can try to do is to run xev, press - and see what key > it is being reported, than bind that. Thank you so much! After some work I manage to have a part of them mapped.
