On Mon, Oct 26, 2020 at 02:24:50PM +0100, Stefan Esser wrote: > The following shell scripts (or configuration files parsed by a > shell) contain literal references to /usr/local: > > libexec/rc/rc.conf # many variables > libexec/rc/rc.shutdown # PATH component > > sys/conf/newvers.sh # search for svnversion, git, hg > > usr.bin/man/man.sh # man_default_path, config_local > > usr.sbin/autofs/autofs/include_ldap # path to ldapsearch > usr.sbin/autofs/autofs/special_media # path to mount.exfat, ntfs-3g > usr.sbin/bsdconfig/bsdconfig # BSDCFG_LOCAL_LIBE > usr.sbin/certctl/certctl.sh # TRUSTPATH, BLACKLISTPATH > usr.sbin/crashinfo/crashinfo.sh # path to gdb > usr.sbin/periodic/periodic.conf # local_periodic variable > > On systems with non-default LOCALBASE these scripts need to be > adjusted. I've one 12.x system with PREFIX/LOCALBASE = /usr/pkg. This is what I'd to change: rc.conf: local_startup ldconfig_paths ldconfig_local_dirs, set $MANPATH, $PATH periodic.conf: local_periodic
All these regressions needs to be fixed of course. Thanks for tacking this. > In the case of rc.shutdown, for example, shutdown routines will > not be executed for a LOCALBASE other then /usr/local. > > The rc.shutdown, autofs/*, certctl.sh, and crashinfo scripts will > be run with root privileges and must not use an untrusted LOCALBASE > value (but could refer to a sysctl variable). The same applies to > the periodic script that relies on the local_periodic variable set > in periodic.conf (but probably overridden in periodic.conf.local, > if required). > > rc.conf could use a $LOCALBASE variable instead of literal values > to construct paths to port/package provided files in order to not > require that each value is modified in the systems /etc/rc.conf > file - which will fail if new variables referring to /usr/local > are introduced in the default configuration). > > The list of shell scripts checked excludes those in contrib, release, tests, > and tools directories, since I think those will be used with > default LOCALBASE, in general. -- Alex _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"