Re: Syncthing permissions question
On Wed, Oct 26, 2022 at 10:38:04PM -0400, Jag Talon wrote: > Hello, > > I'm new to OpenBSD and I'm unfamiliar with permissions in general so I'm a > little lost. I installed syncthing, and it creates the default folder in > /var/syncthing/Sync which is owned by _syncthing and has the group > _syncthing. > > I'm able to read the contents of the directory, but I'm unable to write into > them. I tried adding myself to the _syncthing group by doing: > > usermod -G jag _syncthing > > But it seems that I'm still unable to write to the directory. I know I can > change the ownership of the files by using chmod -R, but new files will > still have the same _syncthing user and group and it seems off to keep > changing permissions of the files. > > How do I enable the user `jag` to read and write to things owned by the > daemon `_syncthing`? > > Thank you so much! > Show ls -ld /var/syncthing/Sync Likely members of the _syncthing group do not have write permissions to that dir. If so, chmod g+w /var/syncthing/Sync should do it. Also: after a usermod command, or any copmmand that changes groups for a user, you would need to re-login as permissions of a login sessino are determined only at login. -Otto
Syncthing permissions question
Hello, I'm new to OpenBSD and I'm unfamiliar with permissions in general so I'm a little lost. I installed syncthing, and it creates the default folder in /var/syncthing/Sync which is owned by _syncthing and has the group _syncthing. I'm able to read the contents of the directory, but I'm unable to write into them. I tried adding myself to the _syncthing group by doing: usermod -G jag _syncthing But it seems that I'm still unable to write to the directory. I know I can change the ownership of the files by using chmod -R, but new files will still have the same _syncthing user and group and it seems off to keep changing permissions of the files. How do I enable the user `jag` to read and write to things owned by the daemon `_syncthing`? Thank you so much!
Recently acquired Ryzen 5 computer lacks sound with OpenBSD 7.1.
The computer has a Ryzen 5 4600G processor, as well as AMD High Def and Realtek audio. I have tried unsuccessfully to get audio through the HDMI connection as well as a Behringer UMC20HD USB sound card. I have looked at the relevant man pages and tried to solve this on Reddit. It has been suggested that I try the fount of all OpenBSD wisdom, so I am posting here. The relevant outputs (thanks to Reddit feedback) can be found here: https://pastebin.com/2rvjWuD7 https://pastebin.com/W26cMyMZ My Reddit post can be found here: https://www.reddit.com/r/openbsd/comments/ydsgo2/recently_acquired_ryzen_5_computer_lacks_sound/ I really like this computer, as OpenBSD appears to run well from it so far, so I am hoping the audio issue can be solved...
VMware Tools driver to advertise OS as 'FreeBSD 64-bit' OS, not 32-bit version
Hello @misc,
I do not see a reason not to update OS version that vmt (kernel level
implementation of VMware Tools) is advertising to VMware hypervisor from
32 bit FreeBSD to 64 bit version.
If for nothing else, there's clock running forward issue that appeared
in 7.2 release and that is solved simply by manually specifying "FreeBSD
64-bit" instead of "FreeBSD 32-bit" for "Guest OS Version".
- https://marc.info/?t=16667408377=1=2
- https://marc.info/?t=16663046932=1=2
Attached is a simple patch that I tested and that changes string
"FreeBSD" to "FreeBSD-64" in a call to "SetGuestInfo" function on
hypervisor and that accomplishes the task.
What could be a drawback? Is author David Gwynne still active and can he
give some feedback?
Index: dev/pv/vmt.c
===
RCS file: /cvs/src/sys/dev/pv/vmt.c,v
retrieving revision 1.26
diff -u -p -u -r1.26 vmt.c
--- dev/pv/vmt.c8 Sep 2022 10:22:06 - 1.26
+++ dev/pv/vmt.c26 Oct 2022 17:01:39 -
@@ -633,7 +633,7 @@ vmt_update_guest_info(struct vmt_softc *
*/
if (vm_rpc_send_rpci_tx(sc, "SetGuestInfo %d %s",
- VM_GUEST_INFO_OS_NAME, "FreeBSD") != 0) {
+ VM_GUEST_INFO_OS_NAME, "FreeBSD-64") != 0) {
DPRINTF("%s: unable to set guest OS", DEVNAME(sc));
sc->sc_rpc_error = 1;
}
Re: sysupdate and space check
Luke A. Call wrote: > On 2022-10-26 11:57:23-, Stuart Henderson > wrote: > > On 2022-10-24, Peter Fraser wrote: > > > I make a stupid mistake; I didn't check partition sizes before doing a > > > sysupgrade. > > > sysupgrade ran out of space or /usr in the middle of the upgrade. > > > I know I should have checked first but it would be nice if sysupgrade did > > > warn me. > > > The site was a 20-minute drive away, and their down time was a lot longer > > > then I expected. > > > > It would be nice, but it's tough to reliably test this without actually > > extracting the files (and a warning with many false triggers wouldn't be > > all that much use either ..) > > Thanks for that info, it is interesting. > > I'm just me, but would definitely prefer a warning that > suggests a potential problem and says what to > check to be sure, over having to do a recovery. I do follow the > instructions and check it (so far, barring mistakes), but I imagine that > the program can still, without extracting the files, check it as well as > I would (df -h...), but more reliably. here you go, you can use this diff. Index: sysupgrade.sh === RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.sh,v retrieving revision 1.48 diff -u -p -u -r1.48 sysupgrade.sh --- sysupgrade.sh 8 Jun 2022 09:03:11 - 1.48 +++ sysupgrade.sh 26 Oct 2022 17:02:35 - @@ -92,6 +92,8 @@ done (($(id -u) != 0)) && err "need root privileges" +echo your /usr might be too small + if $RELEASE && $SNAP; then usage fi
Re: sysupdate and space check
On 2022/10/26 10:48, Luke A. Call wrote: > On 2022-10-26 11:57:23-, Stuart Henderson > wrote: > > On 2022-10-24, Peter Fraser wrote: > > > I make a stupid mistake; I didn't check partition sizes before doing a > > > sysupgrade. > > > sysupgrade ran out of space or /usr in the middle of the upgrade. > > > I know I should have checked first but it would be nice if sysupgrade did > > > warn me. > > > The site was a 20-minute drive away, and their down time was a lot longer > > > then I expected. > > > > It would be nice, but it's tough to reliably test this without actually > > extracting the files (and a warning with many false triggers wouldn't be > > all that much use either ..) > > Thanks for that info, it is interesting. > > I'm just me, but would definitely prefer a warning that > suggests a potential problem and says what to > check to be sure, over having to do a recovery. I do follow the > instructions and check it (so far, barring mistakes), but I imagine that > the program can still, without extracting the files, check it as well as > I would (df -h...), but more reliably. Trouble is, it's highly likely that people who installed with disklabel auto defaults from any version before 7.2-current 2022/06/25 when the default size for /usr was greatly increased will trip a simplistic free space check, though in many of those cases there actually will be enough space to update ok. The "what to check to be sure" is, er, trying to update ...
Re: sysupdate and space check
On 2022-10-26 11:57:23-, Stuart Henderson wrote: > On 2022-10-24, Peter Fraser wrote: > > I make a stupid mistake; I didn't check partition sizes before doing a > > sysupgrade. > > sysupgrade ran out of space or /usr in the middle of the upgrade. > > I know I should have checked first but it would be nice if sysupgrade did > > warn me. > > The site was a 20-minute drive away, and their down time was a lot longer > > then I expected. > > It would be nice, but it's tough to reliably test this without actually > extracting the files (and a warning with many false triggers wouldn't be > all that much use either ..) Thanks for that info, it is interesting. I'm just me, but would definitely prefer a warning that suggests a potential problem and says what to check to be sure, over having to do a recovery. I do follow the instructions and check it (so far, barring mistakes), but I imagine that the program can still, without extracting the files, check it as well as I would (df -h...), but more reliably.
Re: samba maps nodoby as a home share
On Wed 26/10/2022 08:55, kasak wrote: > hello misc! > > Just want to share you some interesting samba behavior after update to 7.2 > > Samba now creates a share named "nobody" when it should not! > > The config is very simple: > > [global] > map to guest = Bad User > server min protocol = NT1 > > [homes] > comment = Home Directories > browseable = No > read only = No > > [share] > path = /mnt/HDD/share > read only = No > guest ok = Yes > guest only = Yes > > > I suspect, that samba improperly bind "nobody" as a "homes" share for guest > user. Setting 'map to guest = Bad User' means that user logins with an invalid password are rejected, unless the username does not exist, in which case it is treated as a guest login and mapped into the guest account. The latter is set to nobody [0]. > I've tried same conf on the fedora machine, with the same version of samba > (4.16.5) and there is no "nobody" share on it. > > So I think this is OpenBSD specific. If I understand smb.conf(5) correctly this is the intended behaviour, which is not specific for OpenBSD. Googling your description seems to confirm this. I can not comment on the behaviour of fedora. [0] https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html#GUESTACCOUNT
Re: sysupdate and space check
On 2022-10-24, Peter Fraser wrote: > I make a stupid mistake; I didn't check partition sizes before doing a > sysupgrade. > sysupgrade ran out of space or /usr in the middle of the upgrade. > I know I should have checked first but it would be nice if sysupgrade did > warn me. > The site was a 20-minute drive away, and their down time was a lot longer > then I expected. It would be nice, but it's tough to reliably test this without actually extracting the files (and a warning with many false triggers wouldn't be all that much use either ..)
dhcpinform only on dhcpd -u
Hi,
in dhcpd.c we have:
if (is_udpsock && packet->packet_type != DHCPINFORM) {
log_info("Unable to handle a DHCP message type=%d on UDP "
"socket", packet->packet_type);
return;
}
Why do we not want to process normal dhcp messages like discover/request?
If you want dhcpd to not bother with raw packets and broadcasts and just focus
on unicasts this would be a logical option.
samba maps nodoby as a home share
hello misc! Just want to share you some interesting samba behavior after update to 7.2 Samba now creates a share named "nobody" when it should not! The config is very simple: [global] map to guest = Bad User server min protocol = NT1 [homes] comment = Home Directories browseable = No read only = No [share] path = /mnt/HDD/share read only = No guest ok = Yes guest only = Yes I suspect, that samba improperly bind "nobody" as a "homes" share for guest user. I've tried same conf on the fedora machine, with the same version of samba (4.16.5) and there is no "nobody" share on it. So I think this is OpenBSD specific.
