Re: patch for test: /etc/shells -> /usr/local/etc/shells
Steve O'Hara-Smith wrote: > > On Fri, 26 Jan 2001 16:21:01 -0500 (EST) > Garrett Wollman <[EMAIL PROTECTED]> wrote: > > GW> < >said: > GW> > GW> > The patch below (against 4-stable but it will probably apply easily > GW> > to -current) moves /etc/shells to /usr/local/etc/shells. > GW> > GW> Bad idea. No base component (never mind libc!) should hard-code a > GW> pathname in /usr/local. > > I'll consider it flamed to death then :) > > It was intended to prevent port installs having to write in /etc > without having to change libc/gen, roken and sendmail which I rather suspect > is also a bad thing to do. > > Perhaps /etc/shells is the least of all evils here. There is a difference between a port creating a config file in /etc, and a port adding to a standard config file in etc. The former is a bad idea, the latter necessary. The other solution would be to allow a PATH of shells files, but that seems rather messy for something this simple. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patch for test: /etc/shells -> /usr/local/etc/shells
On Sat, 27 Jan 2001 16:59:41 -0600 "Jacques A. Vidrine" <[EMAIL PROTECTED]> wrote: JV> I thought you might add it as a different source, so that it need not be JV> the default. As I read it that is still a complementary possibility. The nsdispatch stuff could move the start point from /etc/shells to some other path. The include chain mechanism allows the config to be spread. Have I correctly understood what the nsdispatch stuff can do ? Is it expected to MFC or wait for 5.0 ? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patch for test: /etc/shells -> /usr/local/etc/shells
On Sat, Jan 27, 2001 at 08:48:59PM +0100, Steve O'Hara-Smith wrote: > On Sat, 27 Jan 2001 13:17:22 -0600 > "Jacques A. Vidrine" <[EMAIL PROTECTED]> wrote: > JV> You could just use the nsdispatch() API that is in -CURRENT, and that > JV> getusershell() uses. > > I'm not sure what for, the changes I've made fit just as smoothly > into _local_initshells as they do into initshells. Is there an include > chain follower in there that I've missed ? That's what I've added. It's > working in the test harness and awaiting buildworld. I thought you might add it as a different source, so that it need not be the default. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patch for test: /etc/shells -> /usr/local/etc/shells
On Sat, 27 Jan 2001 13:17:22 -0600 "Jacques A. Vidrine" <[EMAIL PROTECTED]> wrote: JV> You could just use the nsdispatch() API that is in -CURRENT, and that JV> getusershell() uses. I'm not sure what for, the changes I've made fit just as smoothly into _local_initshells as they do into initshells. Is there an include chain follower in there that I've missed ? That's what I've added. It's working in the test harness and awaiting buildworld. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patch for test: /etc/shells -> /usr/local/etc/shells
On Sat, Jan 27, 2001 at 01:57:40PM +0100, Steve O'Hara-Smith wrote: > Life is better than I thought the crypto stuff just has it as a fallback > conditional on HAVE_GETUSERSHELL so that uses the one from libc. Which leaves > only sendmail which is similar but for some reason does not have HASGETUSERSHELL > set for FreeBSD (I think - the conf is convoluted). > > Meanwhile I am building with a getusershell(3) that knows how to follow > a #include (it was already looking for # which pushed the bikeshed marginally > that way). You could just use the nsdispatch() API that is in -CURRENT, and that getusershell() uses. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patch for test: /etc/shells -> /usr/local/etc/shells
On Sat, 27 Jan 2001 00:27:13 -0800 (PST) John Baldwin <[EMAIL PROTECTED]> wrote: JB> How many contrib'd apps need to look at /etc/shells? The biggest one I think JB> is sendmail, and Greg Shapiro is a very reasonable fellow, and can probably JB> assist in getting sendmail at least to use the API as long as it isn't too JB> inconvenient. Life is better than I thought the crypto stuff just has it as a fallback conditional on HAVE_GETUSERSHELL so that uses the one from libc. Which leaves only sendmail which is similar but for some reason does not have HASGETUSERSHELL set for FreeBSD (I think - the conf is convoluted). Meanwhile I am building with a getusershell(3) that knows how to follow a #include (it was already looking for # which pushed the bikeshed marginally that way). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patch for test: /etc/shells -> /usr/local/etc/shells
On Sat, 27 Jan 2001 00:27:13 -0800 (PST) John Baldwin <[EMAIL PROTECTED]> wrote: JB> How many contrib'd apps need to look at /etc/shells? The biggest one I think JB> is sendmail, and Greg Shapiro is a very reasonable fellow, and can probably JB> assist in getting sendmail at least to use the API as long as it isn't too JB> inconvenient. I feel encouraged. The other are it turns up is in the crypto section crypto/heimdal/lib/roken/getusershell.c and /crypto/kerberosIV/lib/roken/getusershell.c I think these are the same. The getusershell seems to be the API to use. It will probably have to be redone in perl for adduser.perl but that's no great problem. Now for the bikeshed question .include or #include ? BTW: I did consider cpp or m4 *briefly*. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patch for test: /etc/shells -> /usr/local/etc/shells
On 27-Jan-01 Steve O'Hara-Smith wrote:
> On Fri, 26 Jan 2001 14:13:42 -0800 (PST)
> John Baldwin <[EMAIL PROTECTED]> wrote:
>
>
> JB> 1) All parsing of /etc/shells should move off into libutil under a
> JB>suitable API.
>
> There is one in libc/gen that would do fine. The catch is that it
> is not used everywhere and some of the code that fails to use it is in
> contrib
> and I am not too sure of the wisdom of changing it.
Hmmm.. How many places use it? sendmail is probably one. If you get a
workable API implemented, we might be able to convince contrib'd apps to use
it, which would be one way of fixing this problem. If you can do that, then
you might be able to work with the maintainer(s) to commit the changes before
the next release of the vendor code comes out on the vendor branch.
> JB> 2) The implementation of this API should allow for multiple files that it
> JB>checks. One way might be to add a '.include' keyword or something so
> JB>that /etc/shells could have '.include /usr/local/etc/shells' that the
> JB>admin could adjust should he/she choose to change ${LOCALBASE} to
> JB>something other than /usr/local.
>
> I did consider an include mechanism and making _PATH_SHELLS a path list.
> I was leaning in the direction of an include mechanism when the (bad) idea of
> changing _PATH_SHELLS to point to /usr/local which removed any need to patch
> roken, adduser.pl and sendmail.
You don't want to statically code a path into _PATH_SHELLS, cause then an admin
has to recompile everything if they change LOCALBASE, which would suck. :)
> JB> This is more work than your patch, but this patch doesn't really solve
> JB> the problem, it merely moves it. It also breaks for ${LOCALBASE}
> JB> != /usr/local, so I don't think it should go in.
>
> Good points, agreed.
>
> Thoughts please on the wisdom of patching the above areas to handle
> an include syntax, my worry is maintenance since most of it is contib. I
> don't
> know if I would be introducing the first changes to them (in which cas I will
> not) or just one of many (in which case I'll start coding). ?
How many contrib'd apps need to look at /etc/shells? The biggest one I think
is sendmail, and Greg Shapiro is a very reasonable fellow, and can probably
assist in getting sendmail at least to use the API as long as it isn't too
inconvenient.
--
John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: patch for test: /etc/shells -> /usr/local/etc/shells
On Fri, 26 Jan 2001 14:13:42 -0800 (PST)
John Baldwin <[EMAIL PROTECTED]> wrote:
JB> 1) All parsing of /etc/shells should move off into libutil under a
JB>suitable API.
There is one in libc/gen that would do fine. The catch is that it
is not used everywhere and some of the code that fails to use it is in contrib
and I am not too sure of the wisdom of changing it.
JB> 2) The implementation of this API should allow for multiple files that it
JB>checks. One way might be to add a '.include' keyword or something so
JB>that /etc/shells could have '.include /usr/local/etc/shells' that the
JB>admin could adjust should he/she choose to change ${LOCALBASE} to
JB>something other than /usr/local.
I did consider an include mechanism and making _PATH_SHELLS a path list.
I was leaning in the direction of an include mechanism when the (bad) idea of
changing _PATH_SHELLS to point to /usr/local which removed any need to patch
roken, adduser.pl and sendmail.
JB> This is more work than your patch, but this patch doesn't really solve
JB> the problem, it merely moves it. It also breaks for ${LOCALBASE}
JB> != /usr/local, so I don't think it should go in.
Good points, agreed.
Thoughts please on the wisdom of patching the above areas to handle
an include syntax, my worry is maintenance since most of it is contib. I don't
know if I would be introducing the first changes to them (in which cas I will
not) or just one of many (in which case I'll start coding). ?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: patch for test: /etc/shells -> /usr/local/etc/shells
On 26-Jan-01 Steve O'Hara-Smith wrote:
> Hi,
>
> Following some recent comments on the evil ways of ports have of
> writing in /etc on install -
This assumes that everyone uses /usr/local for ${LOCALBASE}, which is
not a good assumption to make. If you want to do this right, then ports
should modify ${LOCALBASE}/etc/shells, and a couple of things should
happen:
1) All parsing of /etc/shells should move off into libutil under a
suitable API.
2) The implementation of this API should allow for multiple files that it
checks. One way might be to add a '.include' keyword or something so
that /etc/shells could have '.include /usr/local/etc/shells' that the
admin could adjust should he/she choose to change ${LOCALBASE} to
something other than /usr/local.
This is more work than your patch, but this patch doesn't really solve
the problem, it merely moves it. It also breaks for ${LOCALBASE}
!= /usr/local, so I don't think it should go in.
My $.02.
--
John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: patch for test: /etc/shells -> /usr/local/etc/shells
Louis A. Mamakos <[EMAIL PROTECTED]> types: > I think that /etc/X11 which came along with the XFree86 4 port is a > step in the right direction, too. Frankly, I'd rather have an /etc/local > than /usr/local/etc for that sort configuration data so that it's in > one place, and backed up along with the rest of the hosts's configuration. Other things seem to be moving in the direction of putting default values (that are updated with the system) in /etc/defaults, and local changes in /etc. That would suggest /etc/defaults/shells for the shells installed as part of the base system, and /etc/shells for shells added later, whether from ports or elsewhere. And I want the shed crimson with cream trim. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patch for test: /etc/shells -> /usr/local/etc/shells
> Perhaps /etc/shells is the least of all evils here. I think there's way too much paranoia about software systems putting stuff into /etc. It intended to contain host-specific configuration data I think there's value in having this configuration data in one or very few places so you're not chasing stuff all over the file system. I think that /etc/X11 which came along with the XFree86 4 port is a step in the right direction, too. Frankly, I'd rather have an /etc/local than /usr/local/etc for that sort configuration data so that it's in one place, and backed up along with the rest of the hosts's configuration. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patch for test: /etc/shells -> /usr/local/etc/shells
On Fri, 26 Jan 2001 16:21:01 -0500 (EST) Garrett Wollman <[EMAIL PROTECTED]> wrote: GW> < said: GW> GW> > The patch below (against 4-stable but it will probably apply easily GW> > to -current) moves /etc/shells to /usr/local/etc/shells. GW> GW> Bad idea. No base component (never mind libc!) should hard-code a GW> pathname in /usr/local. I'll consider it flamed to death then :) It was intended to prevent port installs having to write in /etc without having to change libc/gen, roken and sendmail which I rather suspect is also a bad thing to do. Perhaps /etc/shells is the least of all evils here. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
patch for test: /etc/shells -> /usr/local/etc/shells
< said: > The patch below (against 4-stable but it will probably apply easily > to -current) moves /etc/shells to /usr/local/etc/shells. Bad idea. No base component (never mind libc!) should hard-code a pathname in /usr/local. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
patch for test: /etc/shells -> /usr/local/etc/shells
Hi,
Following some recent comments on the evil ways of ports have of
writing in /etc on install -
The patch below (against 4-stable but it will probably apply easily
to -current) moves /etc/shells to /usr/local/etc/shells. It should include
the removal of /usr/src/etc/shells but "cvs diff -N -u ..." did not do what
I exepected :(
After installworld you will have to move /etc/shells to /usr/local/etc
by hand or only the default shells will be known.
To follow (if this is not flamed to death), bsd.ports.mk patch to
automate maintenance of /usr/local/etc/shells during port install, and (of
course) documentation patches (I have a grep).
I am running on this and it works as expected with and without
/usr/local/etc/shells installed and with /etc/shells removed. It needs
more hammering than I can give it to be sure it is safe in all conditions
hence this mail.
Index: include/paths.h
===
RCS file: /home/ncvs/src/include/paths.h,v
retrieving revision 1.9.6.1
diff -u -r1.9.6.1 paths.h
--- include/paths.h 2000/12/11 01:03:16 1.9.6.1
+++ include/paths.h 2001/01/26 07:00:24
@@ -60,7 +60,7 @@
#define_PATH_MEM "/dev/mem"
#define_PATH_NOLOGIN "/var/run/nologin"
#define_PATH_SENDMAIL "/usr/sbin/sendmail"
-#define_PATH_SHELLS"/etc/shells"
+#define_PATH_SHELLS"/usr/local/etc/shells"
#define_PATH_TTY "/dev/tty"
#define_PATH_UNIX "don't use _PATH_UNIX"
#define_PATH_VI"/usr/bin/vi"
Index: etc/Makefile
===
RCS file: /home/ncvs/src/etc/Makefile,v
retrieving revision 1.219.2.9
diff -u -r1.219.2.9 Makefile
--- etc/Makefile2000/11/01 07:21:45 1.219.2.9
+++ etc/Makefile2001/01/26 07:04:28
@@ -13,7 +13,7 @@
printcap profile protocols \
rc rc.atm rc.devfs rc.diskless1 rc.diskless2 rc.firewall rc.firewall6 \
rc.isdn rc.network rc.network6 rc.pccard rc.serial rc.shutdown \
- rc.sysctl remote rpc security services shells syslog.conf usbd.conf \
+ rc.sysctl remote rpc security services syslog.conf usbd.conf \
etc.${MACHINE_ARCH}/disktab \
etc.${MACHINE_ARCH}/rc.${MACHINE_ARCH} \
etc.${MACHINE_ARCH}/ttys \
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
