devnull and urandom not available errors in freebsd hosted server

(1.1) By decuser on 2023-01-07 00:57:43 edited from 1.0 [source]

I'm running fossil server locally on my freebsd 13.1 instance:

/usr/local/bin/fossil server -P 8080 --repolist /zfs/fossils --errorlog fossil.log

It seems to work, but when I navigate to the Server Admin page, I get to warnings (in red letters) that I'd like to "fix" and would appreciate your help:

WARNING: Device "/dev/null" is not available for reading and writing.

WARNING: Device "/dev/urandom" is not available for reading. This means that the pseudo-random number generator used by SQLite will be poorly seeded.

I apparently have both, but the fossil server may not have perms?

ls -l /dev/{null,random}
crw-rw-rw-  1 root  wheel  0x28 Jan  6 12:55 /dev/null
crw-r--r--  1 root  wheel   0x8 Jan  6 10:59 /dev/random

I ran the fossil server command as root and plan to have it started as a daemon by rc at startup.

Thanks,

Will

(2) By Richard Hipp (drh) on 2023-01-07 01:26:44 in reply to 1.1 [link] [source]

They need to be inside your chroot jail.

(3) By Martin Gagnon (mgagnon) on 2023-01-07 01:40:52 in reply to 1.1 [link] [source]

May be this will help you.

It’s not specific to FreeBSD, but may be some part apply to it as well.

Also, it’s possible that the file descriptor 0 SQLite issue is related to the lack of /dev stuff in the jail (perhaps /dev/fd/0 ?)

But I don’t know a lot about FreeBSD, so take it with a grain of salt.

(4) By decuser on 2023-01-07 04:19:16 in reply to 3 [link] [source]

The temporary and not entirely satisfying fix for this is to add --nojail option to the invocation.

The problem stems from this doing a chroot. The recommendation from those more knowledgeable than I is to put it in a jail and make sure devfs is mounted in the jail.

If I figure out a better solution, I'll post back. What's hilarious about this is that I ran into it back in feb and completely forgot about it. The solution then was --nojail. I'm sure it's just my lack of understanding of all things chroot and jail, and who knows, this time it might stick.

https://forums.freebsd.org/threads/dev-null-and-dev-urandom-not-available-in-chroot.84077/

(5) By Stephan Beal (stephan) on 2023-01-07 09:14:21 in reply to 4 [link] [source]

The problem stems from this doing a chroot.

(6) By Konstantin Khomutov (kostix) on 2023-01-07 10:55:03 in reply to 1.1 [link] [source]

As Richard have said, the chroot syscall literally changes the root directory, /, of a process which executes it, to the given directory, and since the /dev hierarchy is rooted at the original /, it becomes inaccessible to the process.

Hence a directory to be chrooted into most of the time should be set up properly beforehand. You might want to refer to jail(8) and especially to jail.conf(5) manual page and the mount.devfs clause which it supports.

(7.1) By decuser on 2023-01-07 15:59:33 edited from 7.0 in reply to 6 [link] [source]

Got it. At the end of the day, a properly installed fossil package and configuration was all that was required. I didn't see the rc file and was definitely making this much harder than it needed to be.

All it takes is

pkg install fossil

vi /usr/local/etc/rc.d/fossil
# add support for fossil_errorlog variable to fossil_args
[ -n "${fossil_errorlog}"  ] && fossil_args="${fossil_args} --errorlog ${fossil_errorlog}"


sysrc fossil_enable="YES"
sysrc fossil_repolist="YES"
sysrc fossil_directory="/zfs/fossils"
sysrc fossil_listenall="YES"
sysrc fossil_errorlog="/zfs/fossils/fossil.log"
service fossil start

Now, the root gets served, the repos get served, there are no dev errors, the errorlog works, and there's no need to disable the backoffice stuff for sqlite warnings to go away.

Thanks all... now, if I can just remember what I learned :).