Re: mpv won't play video : "Consider fixing your graphic drivers"
Le 2023-12-21 04:55, Anthony J. Bentley a écrit : Sylvain Saboua writes: [vo/sdl] Using opengl [vo/sdl] Warning: this legacy VO has bad performance. Consider fixing your graphics drivers, or not forcing the sdl VO. This message is specific to the sdl and xv outputs. The mpv manpage says: The recommended output driver is --vo=gpu, which is the default. All other drivers are for compatibility or special purposes. If the default does not work, it will fallback to other drivers (in the same order as listed by --vo=help). So either you're specifying sdl manually (in a config file?) or the default is not working and mpv is falling back to sdl. Can you confirm which it is? Second, it's a fallback. Nothing even plays and the warning displays in red when specifying --vo=gpu : $mpv --vo=gpu /home/media/E\ -\ Séries/Salem/Salem\ S01/Salem.S01E07.VOSTFR.720p.HDTV.x264-RUDY.mkv (+) Video --vid=1 (*) 'Video' (h264 1280x720 23.976fps) (+) Audio --aid=1 --alang=eng (*) 'Audio' (ac3 6ch 48000Hz) Subs --sid=1 --slang=fre (*) 'Subs' (subrip) [vo/gpu] Failed initializing any suitable GPU context! Error opening/initializing the selected video_out (--vo) device. Video: no video Exiting... (Errors when loading file) $ What could go wrong ? I doubt that it would only be that my computer isn't powerful enough. I have tried different --vo arguments without success. What does "without success" mean? That it continues to fall back to sdl and print that message (say, if you specify --vo=gpu)? I mean that it does not change the behavior at all. I was not aware that the default was overrun however, and hadn't tried --vo=gpu. The error above I got for the first time. -- Sylvain Saboua linktr.ee/Sylvain
Re: mpv won't play video : "Consider fixing your graphic drivers"
Sylvain Saboua writes: > [vo/sdl] Using opengl > [vo/sdl] Warning: this legacy VO has bad performance. Consider fixing > your graphics drivers, or not forcing the sdl VO. This message is specific to the sdl and xv outputs. The mpv manpage says: The recommended output driver is --vo=gpu, which is the default. All other drivers are for compatibility or special purposes. If the default does not work, it will fallback to other drivers (in the same order as listed by --vo=help). So either you're specifying sdl manually (in a config file?) or the default is not working and mpv is falling back to sdl. Can you confirm which it is? > What could go wrong ? I doubt that it would only be that my > computer isn't powerful enough. I have tried different --vo > arguments without success. What does "without success" mean? That it continues to fall back to sdl and print that message (say, if you specify --vo=gpu)?
unwind not picking up autoconf resolver from wg0
I have a setup where a machine has 2 network interfaces:
host fqdn: foo.company.com - public address
vio0 - autoconf'd from internet provider, public IP
wg0 - intranet with it's own DNS intra.company.com dns domain and 10.0.0.0/8
network
Wireguard is configured in star topology, with 10.0.0.1 server providing
org-wide
DNS, router, printing, etc.
unwind.conf: --
forwarder {
1.1.1.1 port 853 authentication name cloudflare-dns.com DoT
1.0.0.1 port 853 authentication name cloudflare-dns.com DoT
}
force accept bogus autoconf {
intra.company.com
}
preference { autoconf forwarder }
wg0 has DNS resolver added using route, as instructed in man resolvd(8)
/etc/hostname.wg0: --
inet ...
wgkey ...
... snip wg vpn config here ...
!route nameserver wg0 10.0.0.1
--
I can definitely observe commented out 10.0.0.1 resolver in /etc/resolv.conf,
as expected when unwind and resolvd are running.
However, when I try to resolve anything with unwind, it fails:
# host foo.intra.company.com localhost
Using domain server:
Name: localhost
Address: 127.0.0.1#53
Aliases:
Host foo.intra.company.com not found: 3(NXDOMAIN)
Resolver on the other side of wg0 is working:
# host foo.intra.company.com 10.0.0.1
Using domain server:
Name: 172.16.0.1
Address: 10.0.0.1#53
Aliases:
foo.intra.company.com has address 10.0.0.xx
When checking autoconf status, I see that unwind is not picking
up resolver from wg0:
# unwindctl status autoconf
autoconfiguration forwarders:
DHCP[vio0]: aa.bb.cc.dd ee.ff.gg.hh
I'm out of ideas here. How can convince unwind to use resolver
from wg0?
Cheers,
Chris
Re: Post (snap) update emails: fsck errors and (in)security output
On Thu, Dec 21, 2023 at 12:16:33AM +0200, Mihai Popescu wrote: > > Why didn't you just bump the daemon datasize in /etc/login.conf to the > > required value? > > this is there for a reason and if you keep "bumping" it, maybe it should be > removed. OK, then: 1. Read the docs and source. 2. Make an educated and informed decision whether to bump it or not based on your own particular requirements and knowledge level. 3. Don't complain on the official OpenBSD lists if you break your own machine, or expect assistance with such a highly customisted configuration.
Re: Post (snap) update emails: fsck errors and (in)security output
> Why didn't you just bump the daemon datasize in /etc/login.conf to the > required value? Because The Creator said once this is there for a reason and if you keep "bumping" it, maybe it should be removed.
Re: Post (snap) update emails: fsck errors and (in)security output
On Wed, Dec 20, 2023 at 07:55:29PM +0100, Why 42? The lists account. wrote: > When I halved the size (memory) allocated (-s=2097152) it mounts > successfully Why didn't you just bump the daemon datasize in /etc/login.conf to the required value?
Re: relayd https inspection certificate issue
On 2023-12-11 14:06, Philipp Benner wrote: Thank you for the infomation Claudio! What a pitty! I thought I found a tiny solution there. Do you have any suggestions for an alternative? I don'´t want to install squid becaus of limited ressources on this machine. Any ideas? Or should I try nginx? Hi list, Just wondering the same question - is there a open source TLS inspection proxy that anyone can recommend besides using relayd's functionality for this ? Thanks, - J
mrouted(8) warnings.
I get these warnings from OpenBSD's mrouted(8). Apart from flooding /var/log/messages, do they actually _mean_ anything, or should I just ignore them? I couldn't find much on the net. Dec 20 20:36:04 niflheim mrouted[92830]: warning - age_table_entry: SIOCGETSGCNT failing for (192.168.3.47 239.255.255.250): Invalid argument Dec 20 21:19:14 niflheim mrouted[92830]: warning - kernel entry already exists for (192.168.3.47 239.255.255.250) -- Eivind Eide "ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL ACHIEVE THE ABSURD" - Oceania Association of Autonomous Astronauts
Re: Weird network performance with iwn(4)
Danel Levai wrote: > Stuart Henderson wrote: > > I checked for openwrt support but your AP has a relatively uncommon > > Realtek SoC and it seems fairly unlikely to happen so you're probably > > stuck with the vendor firmware. > > > > Maybe try forcing "mode 11n" or "mode 11g" with ifconfig and see if > > that's any better. > > Interestingly enough, "mode 11g" won't join the AP. 11n works and it's a > steady > 300KByte/sec, it doesn't go up and down like with 11ac. > > Anyway, I'll see if I can find myself another AP to deploy here, maybe it's > just some > fringe compatibility issue. > > Daniel Just for the record, I totally missed trying the 2.4GHz SSID of this AP (it has a different name). I was only trying 5GHz with all modes - no wonder .11g wouldn't join (brain freeze)... So .11n actually works on 2.4GHz with this AP and iwm(4), and has a download speed of around 1,5-2,0MByte. Daniel
Re: mpv won't play video : "Consider fixing your graphic drivers"
Please post your dmesg. If you don't know what it is or how to get it please search the internet. Tell the list how the /home/media is mounted. Again , if you don;t know how ... search the internet. If you are using some configuration options inside a file for mpv please list them here. I don't think someone on this list is an expert in paranormal nor telepathy guessing and even there is someone it won't be for free :) .
Re: Post (snap) update emails: fsck errors and (in)security output
On Wed, Dec 20, 2023 at 10:57:41AM -0500, Nick Holland wrote: > the ROOTBACKUP process is making an image of a live file system; fsck > grumblings ARE expected. It's just one of those things you aren't supposed > to do (but I do it regularly, because normally, you can get away with it). > > Why the files it is grumbling about are owned by you ... that is a puzzle. > Is your /tmp on a separate partition? If so, it shouldn't be being backed > up by the ROOTBACKUP process. Same for "home" or any other file system you > have access write to. Interesting ... unexpectedly /tmp _is_ part of the root filesystem. I have an entry in fstab to mount it as a seperate mfs filesystem but that has failed for some reason. Probably then this is the reason that the fsck errors are now occurring, being reported, and that I noticed them. Previously, when /tmp was transient, the root filesystem and the altroot fsck process were not affected by content in /tmp. Just tried the mount of /tmp manually from the command line at got: mount_mfs: mmap: Cannot allocate memory When I halved the size (memory) allocated (-s=2097152) it mounts successfully: mjoelnir:robb 20.12 19:50:02 # df -h /tmp Filesystem SizeUsed Avail Capacity Mounted on mfs:75507 1.9G1.0K1.8G 1%/tmp Strange that it used to work. One day (!) I'll re-partition and allocate a partition/slice of "real" storage to /tmp instead of using mfs. > I also see this: > > Backing up root=/dev/rsd1a to /dev/rsd0a: > is sd1a actually your root, and sd0a actually your altroot? > > Second question: Also after an upgrade, the "daily insecurity output" > > contains a huge amount of setuid changes e.g. > > ... > > What actually changed then? > > The files. Aha! - I see. I had in my head somehow understood "Setuid changes:" to mean "changes to the setuid flags/bits of these files ...", not "these files are suid and their content has changed". Maybe that is a better description. > (and yes, I have seen events where a major upgrade caused a lot of noise in > a "something changed" file...which unfortunately hid something we needed to > know about ALSO happened, and was dismissed as "part of the upgrade noise". > This wasn't OpenBSD nor was it a "security event", but it did delay the > detection and repair of a redundancy failure issue because one line was > missed in a sea of thousands of lines of "yeah, that's expected" noise.) It is a fair bit of noise in this case ... even more so with the following "Block device changes" and the even longer "rpki" related section. Thanks! Cheers, Robb.
Re: XFCE Thunar filemanager core dumps ...
On Wed, Dec 20, 2023 at 03:23:52PM -, Stuart Henderson wrote: > > ... > > When I started gdb (no expert) I noticed this "Dwarf error": > > mjoelnir:/tmp 20.12 12:04:38 % gdb -e /usr/local/bin/Thunar -c thunar.core > > GNU gdb 6.3 > > https://www.openbsd.org/faq/ports/ports.html#Backtrace Thanks. What I understood from there then was to install the debug package and run egdb + "bt". Hopefully that's what you had in mind. Here's the resulting stack trace, the "optimized out" sounds a bit worrying :-): (gdb) bt #0 0x084822eb0565 in g_node_traverse_pre_order () from /usr/local/lib/libglib-2.0.so.4201.11 #1 0x084822eb0577 in g_node_traverse_pre_order () from /usr/local/lib/libglib-2.0.so.4201.11 #2 0x084822eb0577 in g_node_traverse_pre_order () from /usr/local/lib/libglib-2.0.so.4201.11 #3 0x084570b35046 in thunar_tree_view_set_show_hidden (view=0x848252483c0, show_hidden=) at thunar-tree-view.c:1990 #4 thunar_tree_view_set_property (object=0x848252483c0, prop_id=, value=, pspec=) at thunar-tree-view.c:509 #5 0x084827e3c82a in object_set_property () from /usr/local/lib/libgobject-2.0.so.4200.18 #6 0x084827e3c5a8 in g_object_setv () from /usr/local/lib/libgobject-2.0.so.4200.18 #7 0x084827e3d94b in g_object_set_property () from /usr/local/lib/libgobject-2.0.so.4200.18 #8 0x084827e2cf19 in on_source_notify () from /usr/local/lib/libgobject-2.0.so.4200.18 #9 0x084827e3442b in g_closure_invoke () from /usr/local/lib/libgobject-2.0.so.4200.18 #10 0x084827e50f4c in signal_emit_unlocked_R.123 () from /usr/local/lib/libgobject-2.0.so.4200.18 #11 0x084827e4ebab in signal_emit_valist_unlocked () from /usr/local/lib/libgobject-2.0.so.4200.18 #12 0x084827e4f39f in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.4200.18 #13 0x084827e40a53 in g_object_dispatch_properties_changed () from /usr/local/lib/libgobject-2.0.so.4200.18 #14 0x084827e3ae1c in g_object_notify_by_spec_internal () from /usr/local/lib/libgobject-2.0.so.4200.18 #15 0x084570b43c07 in thunar_window_action_show_hidden (window=0x848393b6760) at thunar-window.c:4727 #16 0x0847e652dc4e in _gtk_marshal_BOOLEAN__OBJECT_UINT_FLAGS () from /usr/local/lib/libgtk-3.so.2201.0 #17 0x084827e3442b in g_closure_invoke () from /usr/local/lib/libgobject-2.0.so.4200.18 #18 0x084827e4ff6d in signal_emit_unlocked_R () from /usr/local/lib/libgobject-2.0.so.4200.18 #19 0x084827e4ec0f in signal_emit_valist_unlocked () from /usr/local/lib/libgobject-2.0.so.4200.18 #20 0x084827e4f39f in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.4200.18 #21 0x0847e65498d2 in gtk_accel_group_activate () from /usr/local/lib/libgtk-3.so.2201.0 #22 0x0847e6549a24 in gtk_accel_groups_activate () from /usr/local/lib/libgtk-3.so.2201.0 #23 0x0847e686e048 in gtk_window_activate_key () from /usr/local/lib/libgtk-3.so.2201.0 #24 0x0847e6874325 in gtk_window_key_press_event () from /usr/local/lib/libgtk-3.so.2201.0 #25 0x0847e652ceb0 in _gtk_marshal_BOOLEAN__BOXED () from /usr/local/lib/libgtk-3.so.2201.0 #26 0x084827e3442b in g_closure_invoke () from /usr/local/lib/libgobject-2.0.so.4200.18 #27 0x084827e50100 in signal_emit_unlocked_R () from /usr/local/lib/libgobject-2.0.so.4200.18 #28 0x084827e4ec0f in signal_emit_valist_unlocked () from /usr/local/lib/libgobject-2.0.so.4200.18 #29 0x084827e4f39f in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.4200.18 #30 0x0847e684e22a in gtk_widget_event_internal () from /usr/local/lib/libgtk-3.so.2201.0 #31 0x0847e66ce1cf in gtk_propagate_event () from /usr/local/lib/libgtk-3.so.2201.0 #32 0x0847e66cdbe1 in gtk_main_do_event () from /usr/local/lib/libgtk-3.so.2201.0 #33 0x08477220a65b in _gdk_event_emit () from /usr/local/lib/libgdk-3.so.2201.1 #34 0x084772263c88 in gdk_event_source_dispatch () from /usr/local/lib/libgdk-3.so.2201.1 #35 0x084822ea320d in g_main_context_dispatch_unlocked () from /usr/local/lib/libglib-2.0.so.4201.11 #36 0x084822ea35ec in g_main_context_iterate_unlocked () from /usr/local/lib/libglib-2.0.so.4201.11 #37 0x084822ea369b in g_main_context_iteration () from /usr/local/lib/libglib-2.0.so.4201.11 #38 0x0847e42d987d in g_application_run () from /usr/local/lib/libgio-2.0.so.4200.18 #39 0x084570acf399 in main (argc=1, argv=0x7ee77838c528) at main.c:86 mjoelnir:robb 20.12 18:42:54 # pkg_info | grep thunar debug-thunar-4.18.8 debug info for thunar thunar-4.18.8 Xfce4 file manager thunar-archive-0.5.2 Thunar archive plugin thunar-media-tags-0.4.0 Thunar media tags plugin
Re: Post (snap) update emails: fsck errors and (in)security output
On 12/20/23 06:02, Why 42? The lists account. wrote: ... Reply-To: Hi All, A couple of questions ... I have "ROOTBACKUP=1" in /etc/daily.local to replicate my root partition as described in the FAQ (https://www.openbsd.org/faq/faq14.html#altroot) I noticed after an update to a new snapshot via sysupgrade that the next daily output email contains many many fsck "UNREF FILE" errors (See the output included below). Is this expected, or is there some problem? Most or all of the files seem to be owned by me (robb) so I'm thinking that these errors may be related to files in /tmp ... Not sure why this occurs though? the ROOTBACKUP process is making an image of a live file system; fsck grumblings ARE expected. It's just one of those things you aren't supposed to do (but I do it regularly, because normally, you can get away with it). Why the files it is grumbling about are owned by you ... that is a puzzle. Is your /tmp on a separate partition? If so, it shouldn't be being backed up by the ROOTBACKUP process. Same for "home" or any other file system you have access write to. I also see this: Backing up root=/dev/rsd1a to /dev/rsd0a: is sd1a actually your root, and sd0a actually your altroot? Second question: Also after an upgrade, the "daily insecurity output" contains a huge amount of setuid changes e.g. ... -r-xr-sr-x 1 root auth 21144 Nov 30 15:36:52 2023 /usr/bin/skeyinit -r-xr-sr-x 1 root auth 21144 Dec 19 08:35:26 2023 /usr/bin/skeyinit -r-xr-sr-x 1 root _sshagnt 440496 Nov 30 15:36:53 2023 /usr/bin/ssh-agent -r-xr-sr-x 1 root _sshagnt 443856 Dec 19 08:35:26 2023 /usr/bin/ssh-agent -r-sr-xr-x 1 root bin19608 Nov 30 15:36:53 2023 /usr/bin/su -r-sr-xr-x 1 root bin19608 Dec 19 08:35:27 2023 /usr/bin/su -r-xr-sr-x 1 root tty17936 Nov 30 15:36:54 2023 /usr/bin/wall -r-xr-sr-x 1 root tty17936 Dec 19 08:35:28 2023 /usr/bin/wall -r-xr-sr-x 1 root tty14184 Nov 30 15:36:55 2023 /usr/bin/write -r-xr-sr-x 1 root tty14184 Dec 19 08:35:28 2023 /usr/bin/write -r-xr-sr-x 4 root _token 21248 Nov 30 15:36:44 2023 /usr/libexec/auth/login_activ -r-xr-sr-x 4 root _token 21248 Dec 19 08:35:18 2023 /usr/libexec/auth/login_activ ... What actually changed then? The files. Surely many or all of these files had the same permission bits before the upgrade? Maybe these files now have diffent inode numbers, after the upgrade? Why is each filename reported twice? Are these "old" and "new" values? This isn't complaining about the EXISTENCE of setuid programs, it is advising that setuid programs CHANGED from their last recorded version. After all, if I manage to drop a new setuid program on your system, perhaps naming it "ping" or "su", that would be bad, you might want to know about it. Sure, dropping a setuid program that wasn't setuid before could be bad, but replacing an existing one would be more sneaky. You upgraded your machine, so you replaced a lot of setuid programs. And yes, it shows date stamp and size of the old file and the new file. Seeing something bump up or down a few bytes and matching the same date and time stamp of other binaries after an upgrade is expected. Seeing that "su" went from 20k to 70k might warrant investigation. (and yes, I have seen events where a major upgrade caused a lot of noise in a "something changed" file...which unfortunately hid something we needed to know about ALSO happened, and was dismissed as "part of the upgrade noise". This wasn't OpenBSD nor was it a "security event", but it did delay the detection and repair of a redundancy failure issue because one line was missed in a sea of thousands of lines of "yeah, that's expected" noise.) Nick. Thanks in advance for any feedback! Cheers, Robb. Subject: mjoelnir daily output ... OpenBSD 7.4-current (GENERIC.MP) #1535: Tue Dec 19 00:55:53 MST 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP 1:30AM up 7:20, 7 users, load averages: 0.62, 0.44, 0.40 Backing up root=/dev/rsd1a to /dev/rsd0a: 131071+0 records in 131071+0 records out 1073733632 bytes transferred in 10.509 secs (102169077 bytes/sec) ** /dev/rsd0a ** Last Mounted on / ** Phase 1 - Check Blocks and Sizes INCORRECT BLOCK COUNT I=26656 (64 should be 32) CORRECT? yes INCORRECT BLOCK COUNT I=26688 (4128 should be 0) CORRECT? yes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts UNREF FILE I=26064 OWNER=robb MODE=100600 SIZE=4 MTIME=Dec 20 01:30 2023 CLEAR? yes UNREF FILE I=26069 OWNER=robb MODE=10640 SIZE=0 MTIME=Dec 19 19:02 2023 CLEAR? yes UNREF FILE I=26070 OWNER=robb MODE=10640 SIZE=0 MTIME=Dec 20 01:02 2023 CLEAR? yes UNREF FILE I=26073 OWNER=robb MODE=100600 SIZE=28672 MTIME=Dec 20 01:30 2023 CLEAR? yes ... ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? yes SUMMARY INFORMATION BAD SALVAGE? yes BLK(S) MISSING IN BIT MAPS SALVAGE? yes 6103
Re: Bridging firewall and ntpd
On Wed, Dec 20, 2023 at 12:23:31AM +0100, Karel Lucas wrote: >Dear Mr. Henderson, > >From your answer I understand that to use the ntp daemon the interfaces still >need an IP address. Unfortunately, a GPS unit is not available or desirable, >so it seems to me that I will have to do it without a calibrated time, if >there is no other option. Having an out-of-band management interface is a pretty standard architecture concept these days. Add a third NIC and control access by local pf policies, multi-factor authentication, etc.
Re: Appimage
On Tue, Dec 19, 2023 at 10:31:00PM +0200, Mihai Popescu wrote: > > The point of appimage is to work on any Linux distro. > > But it is not working. Like many other ideas created to work on any distro ... > That's a whole other discussion beyond making it work on OpenBSD ;) As I understand it that's because packagers don't understand that you're supposed to include *every* library in your appimage.
Re: XFCE Thunar filemanager core dumps ...
On 2023-12-20, Why 42? The lists account. wrote: > > Hi All, > > I'm running XFCE on OpenBSD 7.4 GENERIC.MP#1535 amd64 > > I pressed Control+h in thunar thinking that it would toggle the display > of hidden files ( .dot files), but instead thunar core dumps: > -rw--- 1 robb robb 20656304 Dec 19 21:02 thunar.core > > Would this be an OpenBSD (porting) issue, or something upstream? > > I don't see this behaviour on an adjacent Linux system (different > versions of XFCE though). I have these versions: > xfce-4.18.1 Xfce desktop meta-package (base installation) > thunar-4.18.8 Xfce4 file manager > > When I started gdb (no expert) I noticed this "Dwarf error": > mjoelnir:/tmp 20.12 12:04:38 % gdb -e /usr/local/bin/Thunar -c thunar.core > GNU gdb 6.3 https://www.openbsd.org/faq/ports/ports.html#Backtrace
mpv won't play video : "Consider fixing your graphic drivers"
I own a 2013 Clevo laptop. Running obsd as daily driver and default/minimalist tools such as cwm, tmux, st, mpv, cmus I have a dedicated partition mounted on /home/media for storing multimedia files : music, movies, series mpv is reluctant to correctly play videos if another process is using the slightest amount of computer resources. For instance at the moment I have only a tmux session inside st running cp to put some music on an sd card. Yet the video won't play, only audio, whereas if mpv is the only process running I can enjoy my series without trouble. $mpv /home/media/E\ -\ Séries/Salem/Salem\ S01/Salem.S01E06.VOSTFR.720p.HDTV.x264-RUDY.mkv (+) Video --vid=1 (*) 'Video' (h264 1280x720 23.976fps) (+) Audio --aid=1 --alang=eng (*) 'Audio' (ac3 6ch 48000Hz) Subs --sid=1 --slang=fre (*) 'Subs' (subrip) [vo/sdl] Using opengl [vo/sdl] Warning: this legacy VO has bad performance. Consider fixing your graphics drivers, or not forcing the sdl VO. AO: [sndio] 48000Hz 5.1(alsa) (5.1) 6ch s16 VO: [sdl] 1280x720 yuv420p AV: 00:00:02 / 00:42:55 (0%) A-V: -0.000 Exiting... (Quit) $ What could go wrong ? I doubt that it would only be that my computer isn't powerful enough. I have tried different --vo arguments without success. -- Sylvain Saboua linktr.ee/Sylvain
Re: Bridging firewall and ntpd
Den tis 19 dec. 2023 kl 23:57 skrev Karel Lucas : > > Hi all, > > I am creating a bridging firewall, and am wondering if it is possible to > use the ntp daemon to ensure that all log files are timed correctly. Is > there a way to achieve that despite the fact that the network > connections do not have an IP address? > I did some of that in the early 2000s, and it wasn't as good an idea as I had imagined it to be. We put an extra eth interface on the box, and had that one on the inside network range, so it could log and be administered via it, then had some rules that allowed certain outside ips to traverse the bridging fw to the inside, and then reach the inside of the fw. But all in all, that was just a workaround for a bad network setup where we got a /24 from our ISP, but not a transport network for our outside of the fw. I would not do it like that again, I noticed how nice it actually is to be able to use layer-3 tools like ping and traceroute and so on, even if it felt secretive and hip to have an "invisible" fw. I think most people that have tried L2 firewalling end up moving away from it if they can, just because of the poor visibility you get when you run firewalls on top of bridges. -- May the most significant bit of your life be positive.
XFCE Thunar filemanager core dumps ...
Hi All, I'm running XFCE on OpenBSD 7.4 GENERIC.MP#1535 amd64 I pressed Control+h in thunar thinking that it would toggle the display of hidden files ( .dot files), but instead thunar core dumps: -rw--- 1 robb robb 20656304 Dec 19 21:02 thunar.core Would this be an OpenBSD (porting) issue, or something upstream? I don't see this behaviour on an adjacent Linux system (different versions of XFCE though). I have these versions: xfce-4.18.1 Xfce desktop meta-package (base installation) thunar-4.18.8 Xfce4 file manager When I started gdb (no expert) I noticed this "Dwarf error": mjoelnir:/tmp 20.12 12:04:38 % gdb -e /usr/local/bin/Thunar -c thunar.core GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-unknown-openbsd7.4". Core was generated by `thunar'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libpthread.so.27.1...done. Loaded symbols for /usr/lib/libpthread.so.27.1 Loaded symbols for /usr/local/bin/Thunar Reading symbols from /usr/local/lib/libthunarx-3.so.0.1...done. Loaded symbols for /usr/local/lib/libthunarx-3.so.0.1 ... Reading symbols from /usr/libexec/ld.so...Error while reading shared library symbols: Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so] Here is some other output, perhaps relevant ... Where: (gdb) where #0 0x0570de714565 in g_node_traverse_pre_order () from /usr/local/lib/libglib-2.0.so.4201.11 #1 0x0570de714577 in g_node_traverse_pre_order () from /usr/local/lib/libglib-2.0.so.4201.11 #2 0x0570de714577 in g_node_traverse_pre_order () from /usr/local/lib/libglib-2.0.so.4201.11 #3 0x056ec2b50046 in thunar_tree_view_set_property () from /usr/local/bin/Thunar #4 0x05711845582a in object_set_property () from /usr/local/lib/libgobject-2.0.so.4200.18 #5 0x0571184555a8 in g_object_setv () from /usr/local/lib/libgobject-2.0.so.4200.18 #6 0x05711845694b in g_object_set_property () from /usr/local/lib/libgobject-2.0.so.4200.18 #7 0x057118445f19 in on_source_notify () from /usr/local/lib/libgobject-2.0.so.4200.18 #8 0x05711844d42b in g_closure_invoke () from /usr/local/lib/libgobject-2.0.so.4200.18 #9 0x057118469f4c in signal_emit_unlocked_R.123 () from /usr/local/lib/libgobject-2.0.so.4200.18 #10 0x057118467bab in signal_emit_valist_unlocked () from /usr/local/lib/libgobject-2.0.so.4200.18 #11 0x05711846839f in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.4200.18 #12 0x057118459a53 in g_object_dispatch_properties_changed () from /usr/local/lib/libgobject-2.0.so.4200.18 #13 0x057118453e1c in g_object_notify_by_spec_internal () from /usr/local/lib/libgobject-2.0.so.4200.18 #14 0x056ec2b5ec07 in thunar_window_action_show_hidden () from /usr/local/bin/Thunar #15 0x0571c0afdc4e in _gtk_marshal_BOOLEAN__OBJECT_UINT_FLAGS () from /usr/local/lib/libgtk-3.so.2201.0 #16 0x05711844d42b in g_closure_invoke () from /usr/local/lib/libgobject-2.0.so.4200.18 #17 0x057118468f6d in signal_emit_unlocked_R () from /usr/local/lib/libgobject-2.0.so.4200.18 #18 0x057118467c0f in signal_emit_valist_unlocked () from /usr/local/lib/libgobject-2.0.so.4200.18 #19 0x05711846839f in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.4200.18 #20 0x0571c0b198d2 in gtk_accel_group_activate () from /usr/local/lib/libgtk-3.so.2201.0 #21 0x0571c0b19a24 in gtk_accel_groups_activate () from /usr/local/lib/libgtk-3.so.2201.0 #22 0x0571c0e3e048 in gtk_window_activate_key () from /usr/local/lib/libgtk-3.so.2201.0 #23 0x0571c0e44325 in gtk_window_key_press_event () from /usr/local/lib/libgtk-3.so.2201.0 #24 0x0571c0afceb0 in _gtk_marshal_BOOLEAN__BOXED () from /usr/local/lib/libgtk-3.so.2201.0 #25 0x05711844d42b in g_closure_invoke () from /usr/local/lib/libgobject-2.0.so.4200.18 #26 0x057118469100 in signal_emit_unlocked_R () from /usr/local/lib/libgobject-2.0.so.4200.18 #27 0x057118467c0f in signal_emit_valist_unlocked () from /usr/local/lib/libgobject-2.0.so.4200.18 #28 0x05711846839f in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.4200.18 #29 0x0571c0e1e22a in gtk_widget_event_internal () from /usr/local/lib/libgtk-3.so.2201.0 #30 0x0571c0c9e1cf in gtk_propagate_event () from /usr/local/lib/libgtk-3.so.2201.0 #31 0x0571c0c9dbe1 in gtk_main_do_event () from /usr/local/lib/libgtk-3.so.2201.0 #32 0x0571359bd65b in _gdk_event_emit () from /usr/local/lib/libgdk-3.so.2201.1 #33 0x057135a16c88 in gdk_event_source_dispatch () from /usr/local/lib/libgdk-3.so.2201.1 #34 0x0570de70720d in
Post (snap) update emails: fsck errors and (in)security output
... Reply-To: Hi All, A couple of questions ... I have "ROOTBACKUP=1" in /etc/daily.local to replicate my root partition as described in the FAQ (https://www.openbsd.org/faq/faq14.html#altroot) I noticed after an update to a new snapshot via sysupgrade that the next daily output email contains many many fsck "UNREF FILE" errors (See the output included below). Is this expected, or is there some problem? Most or all of the files seem to be owned by me (robb) so I'm thinking that these errors may be related to files in /tmp ... Not sure why this occurs though? Second question: Also after an upgrade, the "daily insecurity output" contains a huge amount of setuid changes e.g. ... -r-xr-sr-x 1 root auth 21144 Nov 30 15:36:52 2023 /usr/bin/skeyinit -r-xr-sr-x 1 root auth 21144 Dec 19 08:35:26 2023 /usr/bin/skeyinit -r-xr-sr-x 1 root _sshagnt 440496 Nov 30 15:36:53 2023 /usr/bin/ssh-agent -r-xr-sr-x 1 root _sshagnt 443856 Dec 19 08:35:26 2023 /usr/bin/ssh-agent -r-sr-xr-x 1 root bin19608 Nov 30 15:36:53 2023 /usr/bin/su -r-sr-xr-x 1 root bin19608 Dec 19 08:35:27 2023 /usr/bin/su -r-xr-sr-x 1 root tty17936 Nov 30 15:36:54 2023 /usr/bin/wall -r-xr-sr-x 1 root tty17936 Dec 19 08:35:28 2023 /usr/bin/wall -r-xr-sr-x 1 root tty14184 Nov 30 15:36:55 2023 /usr/bin/write -r-xr-sr-x 1 root tty14184 Dec 19 08:35:28 2023 /usr/bin/write -r-xr-sr-x 4 root _token 21248 Nov 30 15:36:44 2023 /usr/libexec/auth/login_activ -r-xr-sr-x 4 root _token 21248 Dec 19 08:35:18 2023 /usr/libexec/auth/login_activ ... What actually changed then? Surely many or all of these files had the same permission bits before the upgrade? Maybe these files now have diffent inode numbers, after the upgrade? Why is each filename reported twice? Are these "old" and "new" values? Thanks in advance for any feedback! Cheers, Robb. Subject: mjoelnir daily output ... OpenBSD 7.4-current (GENERIC.MP) #1535: Tue Dec 19 00:55:53 MST 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP 1:30AM up 7:20, 7 users, load averages: 0.62, 0.44, 0.40 Backing up root=/dev/rsd1a to /dev/rsd0a: 131071+0 records in 131071+0 records out 1073733632 bytes transferred in 10.509 secs (102169077 bytes/sec) ** /dev/rsd0a ** Last Mounted on / ** Phase 1 - Check Blocks and Sizes INCORRECT BLOCK COUNT I=26656 (64 should be 32) CORRECT? yes INCORRECT BLOCK COUNT I=26688 (4128 should be 0) CORRECT? yes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts UNREF FILE I=26064 OWNER=robb MODE=100600 SIZE=4 MTIME=Dec 20 01:30 2023 CLEAR? yes UNREF FILE I=26069 OWNER=robb MODE=10640 SIZE=0 MTIME=Dec 19 19:02 2023 CLEAR? yes UNREF FILE I=26070 OWNER=robb MODE=10640 SIZE=0 MTIME=Dec 20 01:02 2023 CLEAR? yes UNREF FILE I=26073 OWNER=robb MODE=100600 SIZE=28672 MTIME=Dec 20 01:30 2023 CLEAR? yes ... ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? yes SUMMARY INFORMATION BAD SALVAGE? yes BLK(S) MISSING IN BIT MAPS SALVAGE? yes 6103 files, 101471 used, 412968 free (656 frags, 51539 blocks, 0.1% fragmentation) MARK FILE SYSTEM CLEAN? yes * FILE SYSTEM WAS MODIFIED *
