Re: Some specific software is changing my future..
When I came to code my RADXIDE in Tcl/Tk indeed I found me in the doubt to stay or not at the hosting system game, or better if to choose to implement all the intecom subsystem. Well for me the final decision was easy: the intecom subsystem indeed was already coded but to protect my software (and to save me days of work in adaptation) I decided "to skip" on that. Never to say, that a the opposite site an attacker can exactly have the opposite thought: "intriguing this intercom subsystem between applications, I want to take advantage on it!". > N0\/\/@r€Z > -- > /\/\@rk€T Feb 17, 2024 04:07:08 Nowarez Market : > Hello, > > I need to say that most of the attacks I usually receive in Xfce are on the > file manager (Thunar) or on the console. > So the software most often open on my station. Do you think is it possible to > pay them a special "sandboxing" of > these software in addition to the underwood system protections of OpenBSD? > The most I care for "my friends", > crackers, is clearly about the window system management and for what is my > few knowledge of that part of the system > the underwood intecom system between windows and the framing window system > (mdi windows and relative window > access, disable / enable normal, modal access, etc). Indeed, what I lately > notice more often is their ability to freeze me > the Thunar windows frames and submodals. > > Thanks! > >> N0\/\/@r€Z >> -- >> /\/\@rk€T
Some specific software is changing my future..
Hello, I need to say that most of the attacks I usually receive in Xfce are on the file manager (Thunar) or on the console. So the software most often open on my station. Do you think is it possible to pay them a special "sandboxing" of these software in addition to the underwood system protections of OpenBSD? The most I care for "my friends", crackers, is clearly about the window system management and for what is my few knowledge of that part of the system the underwood intecom system between windows and the framing window system (mdi windows and relative window access, disable / enable normal, modal access, etc). Indeed, what I lately notice more often is their ability to freeze me the Thunar windows frames and submodals. Thanks! > N0\/\/@r€Z > -- > /\/\@rk€T
Re: Automatic OS updates
> On Feb 15, 2024, at 10:12 AM, b...@fea.st wrote: > am I the only one using automatic OS updates > 0 3 * * * root sysupgrade Maybe you meant “syspatch” there? Syspatching via cron is questionable - Some of the patches wont be loaded until the box is rebooted. I think its better to run either syspatch or sysupgrade when i’m in front of the console and can deal with consequences.
Re: Automatic OS updates
On Fri, Feb 16, 2024 at 12:10:18PM -0800, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > At work I manage a herd of a dozen OpenBSD machines. We "upgrade" > by perforing a full network install. +1 All of our servers are upgraded the same way - fresh install, and restore the configuration and user data afterwards. It's perfectly doable, and this method has a lot of benefits.
Re: Automatic OS updates
Kevin Williams writes: > The main use case I see for this is to manage a fleet of more than 10 or > so machines/VMs/instances. rdist or a package such as Ansible could > manage the crontab and possibly search announce@ on marc.info for > keywords to hold off on the upgrade. Blind updating out of cron is utter madness. If there are any merge errors in /etc (think sshd_config for starters), you can end up with a machine you cannot log in to, or that's just acting out destructively. At work I manage a herd of a dozen OpenBSD machines. We "upgrade" by perforing a full network install. The process is pxe boot / fdisk / install / reboot / ansible (create the logins) / reboot / rdist / reboot / verify everything is running correctly (esp. pf), / reboot. The entire process takes 20 minutes per machine, so I can update the entire herd in < 1 day. Although we typically spread it over two or three days. All these machines run as carped a/b pairs, so we upgrade the b hosts first and run on them for a day or two to check for regressions, then upgrade the a machines and switch back to them. The primary reason for installing from scratch is to verify we have not introduced any bugs into the network installation and configuration steps, as this is a core part of our disaster recovery process. It also ensures we launch out of the box with up-to-date packages. And if the number of machines gets entirely out of hand, it should be simple enough semi-automate a good part of the process using expect and some glue. --lyndon
Re: SoGo for OpenBSD?
On Friday, February 16, 2024 21:33 CET, Omar Polo wrote: > On 2024/02/16 16:05:21 +0300, Mark wrote: > > Greetings. > > > > Is there any hero here, to explain/forward me a working tutorial (never > > found one) for installation of SoGo (for its webmail) on an OpenBSD mail > > server? > > Others have already chimed in and pointed you to the `sogo' package, I'd > just like to add that this package, like a few others, installs a readme > file in /usr/local/share/doc/pkg-readmes/sogo with further documentation > on how to set it up. pkg_add will tell you when a package provides a > readme. As the maintainer of the package: As a long time GNUstep user, I don't use the sogo.conf file, but just the GNUstep "defaults" command. In any case, as someone trying to install it "fresh", and feel the README might need some adjustments or updates, I'm happy to take patches. Sebastian > > Cheers, > > Omar Polo >
Re: SoGo for OpenBSD?
On 2024/02/16 16:05:21 +0300, Mark wrote: > Greetings. > > Is there any hero here, to explain/forward me a working tutorial (never > found one) for installation of SoGo (for its webmail) on an OpenBSD mail > server? Others have already chimed in and pointed you to the `sogo' package, I'd just like to add that this package, like a few others, installs a readme file in /usr/local/share/doc/pkg-readmes/sogo with further documentation on how to set it up. pkg_add will tell you when a package provides a readme. Cheers, Omar Polo
Re: Automatic OS updates
The main use case I see for this is to manage a fleet of more than 10 or so machines/VMs/instances. rdist or a package such as Ansible could manage the crontab and possibly search announce@ on marc.info for keywords to hold off on the upgrade. On 2/16/24 08:09, Jan Stary wrote: On 2024-02-15, b...@fea.st wrote: So I was curious, am I the only one using automatic OS updates in cron to keep the fish fresh and the bits dust free? 0 3 * * * root sysupgrade And this saves you what, ten keystrokes a day? Possibly hitting a bad moment to update blindly?
Re: SoGo for OpenBSD?
https://openports.pl/path/www/sogo https://openbsd.app/?search=Sogo > N0\/\/@r€Z > -- > /\/\@rk€T Feb 16, 2024 14:30:01 Peter N. M. Hansteen : > On Fri, Feb 16, 2024 at 04:05:21PM +0300, Mark wrote: >> >> Is there any hero here, to explain/forward me a working tutorial (never >> found one) for installation of SoGo (for its webmail) on an OpenBSD mail >> server? > > I must admit I had never heard of the thing before reading your message, > but there appears to be a www/sogo port, so "doas pkg_add sogo" and proceed > to any configuration steps the docs specify should be a possible way forward. > > - Peter > > -- > Peter N. M. Hansteen, member of the first RFC 1149 implementation team > https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/ > "Remember to set the evil bit on all malicious network traffic" > delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: ntpd: "DNS lookup tempfail" when running on an IPv6-only node
This node is running with IPv6-only. Since I did not have IPv4, I initially only commented the constraint with IPv4 . But it was not enough. Then I realised that pool.ntp.org doesn't include a record. That is ntppool's decision. I ended up by commenting the servers line and added several servers close enough . I posted my question on github [1] and someone advised me to rely on "2.openbsd.pool.ntp.org" Is it possible the default ntpd.conf file use something like "servers openbsd.pool.ntp.org" and of course have openbsd.pool.ntp.org looking for IPv6 nodes? openbsd.pool.ntp.org won't help, that doesn't have records either. Perhaps the usage of DNS64 + NAT64 could help. Gábor
Re: Automatic OS updates
> On 2024-02-15, b...@fea.st wrote: > > So I was curious, am I the only one using automatic OS updates > > in cron to keep the fish fresh and the bits dust free? > > 0 3 * * * root sysupgrade And this saves you what, ten keystrokes a day? Possibly hitting a bad moment to update blindly?
Re: SoGo for OpenBSD?
On Fri, Feb 16, 2024 at 04:05:21PM +0300, Mark wrote: > > Is there any hero here, to explain/forward me a working tutorial (never > found one) for installation of SoGo (for its webmail) on an OpenBSD mail > server? I must admit I had never heard of the thing before reading your message, but there appears to be a www/sogo port, so "doas pkg_add sogo" and proceed to any configuration steps the docs specify should be a possible way forward. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
SoGo for OpenBSD?
Greetings. Is there any hero here, to explain/forward me a working tutorial (never found one) for installation of SoGo (for its webmail) on an OpenBSD mail server?
Re: Automatic OS updates
On 2024-02-15, b...@fea.st wrote: > So I was curious, am I the only one using automatic OS updates > in cron to keep the fish fresh and the bits dust free? > > I think I read somewhere that it's not recommended but I'm not > running a server so it seems like a good idea to me. > > /etc/crontab: > > # Example of job definition: > # . minute (0 - 59) > # | .- hour (0 - 23) > # | | .-- day of month (1 - 31) > # | | | .--- month (1 - 12) OR jan,feb,mar,apr ... > # | | | | . day of week (0 - 6) (Sunday=0 or 7) OR > sun,mon,tue,wed,thu,fri,sat > # | | | | | > # * * * * * user-name command to be executed > 0 3 * * * root sysupgrade You should read upgrade notes (faq/current.html for -current, faq/upgradeXX.html for releases) *before* upgrading. For -current you should really be aware of commits (read src-changes) so you can identify times which would be bad to update (often best to hold off for a few days after a major library bump or major perl version update in order that new packages are available). -- Please keep replies on the mailing list.
Re: relayd fallback when using tag/tagged
Le 2/15/24 à 10:33, Michael Hekeler a écrit :
Hello,
I'm trying to configure relayd(8) to use tags, to allow legit host names
only and modify HTTP headers, and fallback. But I can't have it working
properly.
I don't understand exactly what you want to achieve. Do you want:
A. Requests with http header "www.example" going to primary.
And going to fallback if primary is down.
And block all other requests.
or:
B. Request with http header "www.example" going to primary.
And all other going to fallback.
And block nothing (=all requests are served either by primary or
by fallback)
It looks more like A.
I want to relay to the primary by default.
I the primary fails, then I want to relay to a secondary. Which is just
a static webpage saying "work in progress, be back soon".
If A) then put both servers in the table and let HCE decide which host
is up. Something like that (header check ignored in example):
table {192.0.2.4 192.0.2.7}
redirect www {
listen on 192.0.2.30 port 80
forward to check http “/” code 200
}
This implies "mode roundrobin" which is not what I want. The secondary
should only be displayed when the primary is down.
If B) then you need an an additional pass rule in your protocol.
Something like that (to be honest I don't know why you need the tag here
so I ignored that in that example):
http protocol www {
pass request quick header "Host" value "www.example" \
forward to
pass request forward to
block
}
I need tags because the relayd(8) exposes several FQDN and sets various
headers depending on those.
Using such a configuration:
#-8<---
table { 192.0.2.4 }
table { 192.0.2.7}
http protocol www {
block
match request header "Host" value "www.example" tag "example"
pass request tagged "example" forward to
}
relay www {
listen on 192.0.2.30 port 80
protocol www
forward to port 80 check http "/" code 200
forward to port 80
}
#-8<---
forwards all tagged HTTP traffic to the primary server. But if it is turned
off, relayd(8) only replies with error rather than sending the traffic to
the fallback server.
Removing tags and using a simple "pass" directive in protocol (as described
in the man page) does work as expected regarding the fallback server.
Is there a way to use both tags and fallback with relayd(8) to mimic
Apache's Failover[1] configuration with "ProxyPass" and "BalancerMember
(...) status=+H" ?
Thank you,
Joel C.
[1] https://httpd.apache.org/docs/trunk/howto/reverse_proxy.html#failover
--
Bonne journée,
Joel C.
Tél: +33 663541230
