Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
Oliver Eikemeier wrote: The reason I did this was to support services like mail and nss_ldap. I really like to be prefix safe, PR conf/56736 relates to this: http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/56736 I agree that there should be a better solution, and already asked Mike Makonnen [EMAIL PROTECTED] about it, but nobody seemed to care. IMHO not participating in rcorder(8) makes the packing list pettier and avoids an ugly hack, which is good, but restrains functionality. I like the idea of account managed in an centralized LDAP directory very much. So, do you still think the scripts should not participate in rcorder(8)? It's easy to change the ports, but this is probably not the right fix. -Oliver I guess I don't see the problem. What is wrong with ports adding startup scripts to /etc/rc.d? For certain ports, that is the only way to get the startup dependencies right (like making sure openldap or postgresql starts before your mail system). This will become more important as more of the base system moves to ports/packages. Just refine the note in UPDATING to specifically state which startup scripts to remove, rather than rm -rf /etc/rc.d/*. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
Andreas Klemm wrote: What about simply putting a number in front of the script, I didn't check but am really certain that we start scripts something like this: cd $LOCALBASE/etc/rc.d for i in *.sh --- here you get an alphabetically sort order ! do if [ -x $i ]; then /bin/sh $i start fi done So this would be sufficient to start slapd before slurpd: /usr/local/etc/rc.d/001.slapd.sh /usr/local/etc/rc.d/002.slurpd.sh or alternatively /usr/local/etc/rc.d/openldap-01-slapd.sh /usr/local/etc/rc.d/openldap-02-slurpd.sh We already have things like: 000.mysql-client.sh 000.pkgtools.sh 000.wine.sh 010.pgsql.sh Andreas /// That works fine if you are only concerned about startup ordering for things in /usr/local/etc/rc.d. Although it would be better if we could use rcorder style dependency ordering here as well. But it doesn't help if you need a port to start earlier than something in the base. This could happen if you've replaced sendmail with postfix, and use maps from a remote database (openldap, postgresql, etc). I'm sure there are other examples as well (nss_ldap, etc). Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
Andreas Klemm wrote: I guess I don't see the problem. What is wrong with ports adding startup scripts to /etc/rc.d? For certain ports, that is the only way to get the startup dependencies right (like making sure openldap or postgresql starts before your mail system). This will become more important as more of the base system moves to ports/packages. Just refine the note in UPDATING to specifically state which startup scripts to remove, rather than rm -rf /etc/rc.d/*. As I wrote im my previous mail we could import wrapper scripts for such basic services, since there are only few services that are so generic, that they have to be available so early in boot order. I strongly would dislike creating ports to install stuff under /etc/whatever. This would start to violate things for what I liked FreeBSD for all these many years and I hope/think other have the same feeling concerning this. Andreas /// But that kinda defeats the purpose of RCNG. One of the best features of RCNG is that it makes it easier to add/delete applications from the system. Not using it for this purpose reduces its utility. Let's not let the typical BSD traditionalism get in the way of using RCNG for what it's designed. Don't get me wrong. I'm not advocating Linux-style integration of packages/ports. But this seems fairly harmless. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
Dag-Erling Smørgrav wrote: Melvyn Sopacua [EMAIL PROTECTED] writes: Then you can just as easily nuke the entire mailer.conf principle and symlink bin/postfix to etc/rc.d/050.postfix.sh. This is actually one of the two recommended ways of starting postfix (and the one I prefer). The main reason for mailer.conf to exist is that a lot of scripts have /usr/sbin/sendmail hardcoded and TPTB decided that they didn't want to use 'use.perl port'-style symlinks. DES But all these seem like such hacks. It would be so much cleaner to move sendmail.sh out of the way and just add postfix.sh to /etc/rc.d, rather than using tricks with symlinks and rc.conf variables. If you have a small number of ports added, it's not a big deal. But all these hacks get confusing when you have a lot of ports, each doing it's own special trick. The mailer.conf issue (for mail injection) is a separate issue and there's really no way around that. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
Melvyn Sopacua wrote: Isn't that *exactly why* ports should respect $PREFIX? At least than you know that startup scripts are in one place. Maybe all that is needed is a variable RCDIR?= etc/rc.d, for people who want to 'deviate' from this convention. I like that idea. That could work. But to make this seemless (in the case of RCDIR=/etc/rc.d), we would need to start adding the RCNG keywords to the startup scripts added by ports. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
Matthias Andree wrote: Richard Coleman [EMAIL PROTECTED] writes: But that kinda defeats the purpose of RCNG. One of the best features of RCNG is that it makes it easier to add/delete applications from the system. Not using it for this purpose reduces its utility. Let's not let the typical BSD traditionalism get in the way of using RCNG for what it's designed. Don't get me wrong. I'm not advocating Linux-style integration of packages/ports. But this seems fairly harmless. Ports belong into /usr/local, not into /etc. There should be some hook that allows port start scripts to run before some base system scripts, and if Oliver's two-staged reevaluate approach supports this with / and /usr in separate partitions, then why not take his suggestion? There's nothing that prevents RCNG from stretching out its fangs to /usr/local/etc/rc*, in fact, hier(7) encourages that. If I get the picture right, what's suggested is that after mounting local file systems, the RC order is re-evaluated, and again after mounting remote file systems (diskless). This would allow the system to gradually complete its /etc/rc* picture. Another idea would be to use unionfs or something to keep /usr/local/etc/rc.d in the root partition for real, and when it's shadowed by the actual /usr/local or /usr mount, punch a hole so you can look at the rootfs with unionfs or something. I'd like Oliver's suggestion better though. I guess I'm not really arguing for putting the startup scripts for ports in /etc/rc.d (contradicting what I said earlier). But I do think that RCNG/rcorder needs to be extended to handle ports. And it needs to be done in a more comprehensive fashion than just adding special hooks for backend databases. The multiple rcorder evaluation method you mention sounds like a good place to start. The unionfs idea is also interesting. But I doubt many people trust it enough to use it for this purpose. It's a shame really, but that's another discussion. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
David O'Brien wrote: For 5.2-CURRENT, I think we should revisit this issue with one of the following conclusions winning out, and the rest being discarded as flame-bait: (1) Combine / and /usr into a single file system by default, and add /usr/local/etc/rc.d to the search order, with appropriate hacks to handle old-style scripts. The devil will be in the bikeshed, but the implementation is easy, except for the bit where we explain that NFS-mounted /usr/local won't work too well. I would like to show support for this option. I've been running /usr on the / partition on *all* my FBSD machines for the past 4 years. The reasons for having a separate / and /usr just don't apply today. Disks are large enough to hold both, and UFS(FFS) is stable. Sun and SGI both combine / and /usr on their pre-installed workstation machines. That abandons the ability to have a read-only /usr. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports startup scripts in /etc/rc.d (Re: 5.2-BETA and related ports issues)
Robert Watson wrote: For 5.2-CURRENT, I think we should revisit this issue with one of the following conclusions winning out, and the rest being discarded as flame-bait: (1) Combine / and /usr into a single file system by default, and add /usr/local/etc/rc.d to the search order, with appropriate hacks to handle old-style scripts. The devil will be in the bikeshed, but the implementation is easy, except for the bit where we explain that NFS-mounted /usr/local won't work too well. (2) Reevaluate the order at routine points in the boot where new scripts might now be available (due to file system mounts or whatever). Essentially insert the new cards into the deck, and shuffle. This requires rethinking of our current approach, which assumes a static order is created once at the start of the boot by rcorder(8). The devil will be in the big picture *and* the details of the implementation. (3) Add /local/etc/rc.d or /local/rc.d or /etc/local/rc.d or the like, a new directory that third party applications are allowed to modify during install, and that will be present for the creation of the static ordering by rcorder(8) early in the boot. The devil will be in the bikeshed, but the implementation is easy. (4) Continue to ignore the issue and let some ports install into /etc/rc.d and consider them unorthodox, incorrect, but something we can overlook. The devil isn't here, or at least, if it is, we'll overlook it. I'm actually leaning towards (2) as being the best solution, as it's easy and functional. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Senior Research Scientist, McAfee Research I think this message sums up the options quite nicely. I like option 2 the best, with option 3 a close second. I think either would be an acceptable compromise. Option 1 abandons the ability for read-only /usr, which many people like. That and the NFS problems that Robert mentioned should rule this out. But I like anything over doing nothing (option 4). Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM (was Re: NSS and PAM, dynamic vs. static)
slave-mike wrote: why does /bin/sh need NSS support? 1. If you are using pam_ldap, tilde expansion will be broken in /bin/sh without nss_ldap support. 2. Tilde expansion is required for POSIX conformance. It's not the strongest rationale. But it's something to consider. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
Andreas Klemm wrote: The following rc.d scripts have been removed and should be deleted from your installation: atm2.sh atm3.sh devdb localdaemons network1 network2 network3. Depending on when you last updated world and used mergemaster(8) you may or may not have problems during the rc boot sequence. The simplest solution is an 'rm -rf /etc/rc.d/*' and then 'mergemaster -i'. The atm2.sh atm3.sh and devdb scripts were removed some time ago, so depending on when you installed -CURRENT these scripts may or may not exist on your system. I can't recommend doing it this way, since some ports I know are writing startup scripts to /etc/rc.d :-/ Cc'd to port maintainer to sanitize this All openldapXX-server ports do this for example [EMAIL PROTECTED] /var/db/pkg grep /etc/rc.d */+CONTEN* [...] openldap-server-2.1.23/+CONTENTS:@unexec /etc/rc.d/slapd stop 21 /dev/null || true openldap-server-2.1.23/+CONTENTS:@unexec /etc/rc.d/slurpd stop 21 /dev/null || true openldap-server-2.1.23/+CONTENTS:@cwd /etc/rc.d It's too bad that portlint doesn't catch this. I wonder how hard it would be to add such detection. It already does some pretty amazing stuff already. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Need example file for nsswitch.conf in /usr/share/examples
There really needs to be an example file for nsswitch.conf in /usr/share/example. For people new to FreeBSD 5.X, there is no outward sign that nsswitch is supported other than the nsswitch.conf(5) man page. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM
Dag-Erling Smørgrav wrote: NSS itself doesn't make much sense to me; it's an elaborate hack designed to drag all those nice shiny directory services down in the mud where struct passwd has been wallowing for the past twenty years, instead of allowing applications to take advantage of their superior functionality. As for PAM, a lot of what's wrong with it today could be fixed by redesigning it to include directory services. If you fixed the conversation system (by formalizing service function execution as an FSM) and cleaned up the configuration syntax, you'd end up with something quite nice. DES Replacing passwd/group/NSS/PAM/whatever with a real database or directory backend is a kind of holy grail for Unix that's been discussed for many years. I would love to see it happen. But I doubt it could ever happen within a collaborative project like FreeBSD, since it would be impossible to get enough people to agree upon the innumerable small details. I don't want to sound so pessimistic, but I think that's just a reality of group projects. I think this is part of the reason that many people are passionate about the dynamic library implementation of PAM/NSS. We realize that the odds are very high that the alternatives will be endlessly discussed, but never implemented. Since this is a feature that many of us really need, we prefer the less than perfect but existing implementation to the perfect, but never implemented solution. This discussion has really reminded me of the classic paper by Richard Gabriel on Lisp: Good News, Bad News, How to Win Big. This is one of the best essays on the Worse is Better phenomenon. http://www.ai.mit.edu/docs/articles/good-news/good-news.html http://www.dreamsongs.com/WorseIsBetter.html Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
Andrew Gallatin wrote: So I think the best solution (*) would be to keep /bin/sh statically linked, and build a dynamic version in /usr/bin that people can use as an interactive shell. Root's shell remains /bin/sh 1) All three (;-) interactive bourne shell users that use nss/ldap get tilde expansion. 2) 3rd party scripts, which are written to be portable and don't use tilde, don't have to pay for dynamic linking. 3) System startup scripts are faster because they use the static /bin/sh Are you suggesting that (t)csh also move to /usr/bin to match /usr/bin/sh? The screams caused by such a change would be deafening. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
Tim Kientzle wrote: David O'Brien wrote: On Mon, Nov 24, 2003 at 12:08:58PM -0800, Tim Kientzle wrote: ... I think [/rescue] only needs to support those recovery actions necessary to repair /bin and /sbin if they break. My stance is that no failure mode needs to be repairable that wasn't repairable with a static /. I'm willing to compromise, David. Here's what I suggest: * I could support removing vi/ex from /rescue. * In exchange for this concession, would you be willing to support adding fetch? I expect this exchange would result in a net 150-200 kB savings in /rescue. How about it? Tim I think a better compromise is to add the make.conf option so that extra utilities may be added to /rescue. Then leave both vi and fetch out of the default. With the size of disk drives these days, (for my own setup) I'm tempted to just add a complete copy of /bin and /sbin into /rescue. The extra 100 meg doesn't take much out of a 80 gig hard drive. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Make it so that nobody wins
Neither side of the static/dynamic root debate wants to give in. And neither side wants to be one the that has to recompile the world to get what they want. So make it so that no one wins. 1. Have sysinstall ask whether you want a dynamic or static root installed. 2. When recompiling the world, make it mandatory that DYNAMICROOT=YES/NO exits in make.conf. Neither side wins, neither side loses. Now both side will hate it equally. Of course, I'm only being half serious. But in a bizarre way, it kinda makes sense. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
David O'Brien wrote: We should build /bin/sh static and be done with the argument. Or rather, lets find a /bin/sh interactive user and have him argue that /bin/sh needs NSS support. I dare say that will be a thread two orders of magnitude shorter than this one. Statically linking /bin/sh wouldn't be that big a deal. It would be trivial to add a port to compile a dynamic version of sh for customers that *really* want sh. Personally, I can't remember a customer specifically requesting that. You would need to make sure that startup scripts never use tilde expansion. I'm not sure how common that is with RCNG. But it would be sorta odd to have statically linked versions of sh in both /bin and /rescue. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
Garrett Wollman wrote: You forgot: * Allow statically-linked programs to use dynamic NSS modules by forking a (dynamically-linked) resolver process when needed. This leads to a related, but widely disparaged option: * Have a persistent NSS caching daemon with an RPC interface that all programs can access for NSS lookups. You might call such a program `nscd'. (Might as well be honest about it.) Both of these options may incidentally help to resolve threading issues in the C library (although that would not be the preferred way of doing so). Regardless of how NSS is implemented, it will be useful to have some type of caching (even if optional). On a large system, you can beat the hell out of your LDAP server otherwise. Of course, you can use a local replica of your LDAP server. But that doesn't help if are using a different database like Postgres as the backend for your nss/pam setup. But if a nscd (or equivalent) is added to FreeBSD, we need to do a better job than the Linux nscd. We had real problems with the Linux nscd in a previous project. If I remember, it assumes that the mapping between username - uid was 1-1. We added an attribute to our LDAP schema so we could specify the reverse mapping in situations where more than one username mapped to the same uid. But we could never get it to work correctly, since Linux nscd made some assumption that were difficult to change. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
M. Warner Losh wrote: : I agree. termcap.small is amazingly uncurrent. However, perhaps some : merging and reducing is in order. Why is a full cons25 or vt2xx needed? : vi only needs a few capabilities. I think we mostly use copies of large : termcap entries because copying the whole things is easier. You have a good point. My termcap was done so that we could run a number of applications... Grepping seems unsatisfying to find out which keys are used. Do you have a list? Warner Is the extra maintenance worth it to save a few hundred bytes? It might even make sense to dynamically generate termcap.tiny at build time by pulling out the entries in /etc/termcap for a selected list of terminal types. Then, no extra maintenance would be needed. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
boyd, rounin wrote: how about no copy of vi, or termcap and one copy of ed? Is this where we start swapping stories about when I was a young sysadmin, we didn't need no stinkin vi. We used ed and liked it!. :-) Actually, as a sysadmin who's grown old, fat, and lazy, I would prefer to not need to use ed ever again. There's no need to be masochistic. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
boyd, rounin wrote: From: Dimitry Andric [EMAIL PROTECTED] % sudo ldd /sbin/init /sbin/init: libutil.so.3 = /lib/libutil.so.3 (0x28074000) libcrypt.so.2 = /lib/libcrypt.so.2 (0x2807f000) libc.so.5 = /lib/libc.so.5 (0x28097000) Yes, working fine here. What should the problem be? the day /lib gets smashed. you're building a house of cards. once, if /etc/init and /bin/sh and some other pieces where in place a smashed file-system could be easily fixed. now you have to have 3 shared libs and a viable /lib. do you want systems that work? or houses of cards? I would prefer to solve this problem using a fixit floppy or cdrom anyways. I don't think that creates a house of cards. My systems work just fine. But I've often wondered how frequently a production system has such problems. I've been a sysadmin for many years and can't remember this ever happening. It's much more common to blow a hard drive, or have flaky memory, etc. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
boyd, rounin wrote: From: Christopher Vance [EMAIL PROTECTED] Personally, I think init should be static, and can't think of any way it would benefit from shared libraries. plan 9 has everything static. the kernel compiles in about 20 seconds or less -- no compression -- and you can boot it off a floppy. if i can sit in /sys/src and type: mk install and have everything re-built (and i could do it for all the supported architectures) in minutes i have eliminated unnecessary complexity. if it's not there, it can't break. btw: say hi to maltby for me. plan9 doesn't count. It's so minimalistic, it's useless. It has many beautiful and brilliant ideas. But it's not useful to many people as a production system. It's a shame, really. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
Tim Kientzle wrote: I'm pretty comfortable with the failsafes that we have in place: * /sbin/init is static * If /bin/sh fails, /rescue/sh can be run * /rescue provides a complete set of statically-linked sysadmin utilities that should be sufficient for recovering a damaged system. There are a few things I'd like to see: * It would be nice if the kernel noticed that /sbin/init failed too quickly and prompted the user for an alternate init. That would open the door to a dynamic or just more ambitious /sbin/init, since you could always fall back to /rescue/init for recovery. * /rescue/vi is currently unusable if /usr is missing because the termcap database is in /usr. One possibility would be to build a couple of default termcap entries into ncurses or into vi. Just put a tiny termcap file in /rescue (i.e. termcap.rescue) that contains 5 or 6 of the most common terminal types (cons25, vt102, etc), and have /rescue/vi default to cons25. That is cleaner than hard coding them into /rescue/vi. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
Gordon Tetlow wrote: On Tue, Nov 18, 2003 at 08:03:23PM -0500, [EMAIL PROTECTED] wrote: However, PAM and NSS 'tricks' really seem to be exactly that, and certainly worthy of special builds. However, that isn't necessary, yet still not building everything with a shared libc. Things like nss_ldap (which is used *heavily* at my place of employment) are some reasons that FreeBSD doesn't make it into more places. It was the reason why FreeBSD isn't being used here. Calling them 'tricks' (and succumbing to the name calling you wanted to avoid) doesn't change the fact that every major contender (IRIX, Solaris, Linux to name a few) all support this feature set. The fact that you can't easily do centralized authentication (nss_ldap and pam_ldap) with FreeBSD is a major show stopper. At my former employer, we built several very large systems that required centralized authentication using ldap. We had to use Linux, since none of the BSD's supported this correctly at the time. I don't really care whether everything is statically or dynamically linked. With the fast machines and huge disks these days, bloat is not much of an issue. But nss and pam need to work correctly. If the folks that are against dynamic linking have an alternate method to make this work, I'm all for it. But it needs to be more than theory. We need code. To be honest, I've never understood the (seemingly irrational) resistance against this change. Solaris made this change 10 years ago. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
Dan Nelson wrote: In the last episode (Nov 19), Richard Coleman said: I don't really care whether everything is statically or dynamically linked. With the fast machines and huge disks these days, bloat is not much of an issue. But nss and pam need to work correctly. If the folks that are against dynamic linking have an alternate method to make this work, I'm all for it. But it needs to be more than theory. We need code. To be honest, I've never understood the (seemingly irrational) resistance against this change. Solaris made this change 10 years ago. Not completely: $ uname -a SunOS pd1 5.9 Generic_112233-08 sun4u sparc SUNW,Ultra-Enterprise $ file /bin/sh /sbin/sh: ELF 32-bit MSB executable SPARC Version 1, statically linked, stripped $ file /sbin/* | grep statically | cut -d: -f1 | fmt /sbin/autopush /sbin/fdisk /sbin/jsh /sbin/mount /sbin/sh /sbin/soconfig /sbin/sync /sbin/umount /sbin/uname I have no problem with FreeBSD doing something similar and leaving a few binaries static. I think most of the resistance to that was due to the increased complexity of the build system. It seems /bin/sh is the real sticking point. But if the compromise is to statically link /bin/sh, that would be cool with me. Other than tilde expansion not working when using nss_ldap, I can't think of any other problems. I consider that a minor blemish I could easily live with. Normal users will not generally have /bin/sh has their shell anyways. And I could always compile a dynamically linked version into /usr/bin if necessary. To be honest, 98% of the time that someone notices brokeness due to nss_ldap, it comes when using /bin/ls. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
Robert M.Zigweid wrote: I'll admit to being mostly a lurker here, but isn't the point of /sbin to be statically linked. That's what the 's' stands for? Second question. This seems to imply that /sbin and /bin both have to have the same behavior? I have no problem with /bin being dynamically linked, but what if I want /bin to be dynamic and /sbin static? Regards, Robert M. Zigweid I'm not sure what that would accomplish. If a system was broken such that the dynamically linked binaries in /bin didn't work, the utilities in /sbin wouldn't be enough to fix the system. For instance, you wouldn't have a shell or ls. Statically linked binaries to fix a hosed system are now in /rescue. Check man hier. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
Bill Vermillion wrote: 1) Much smaller /bin and /sbin. On i386, /bin and /sbin are 33 MB static. Dynamically linked, they are only 4 MB. I don't think saving that little space on the / partition is as important as having everthing in sbin being able to stand alone no matter what is corrupted. If you need to recover from a corrupted system, why is it so important to use /bin or /sbin, when /rescue is there for that exact purpose? I think it is much more important that nsswitch.conf work properly. But I think the time for these discussions is passed. I think at this stage the important thing is to make it work correctly. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: signal 12's everywhere on Current with update this morning.
Someone just needs to bring the build(7) man page up to date with the handbook. Also, I noticed that build(7) still lists the installmost build target. I believe that was removed. I would file a PR except that my man pages always suck. Richard Coleman [EMAIL PROTECTED] Brent Jones wrote: If this is true, perhaps the build man page should be updated. Here's what the man page has to say on the topic: The ``approved'' method of updating your system from the latest sources is: make buildworld make buildkernel KERNCONF=FOO make installkernel KERNCONF=FOO make installworld mergemaster After running these commands a system reboot is required... This gives the impression that you're safe running all the builds without rebooting, especially as the word approved is used. Brent On Nov 13, 2003, at 11:18 PM, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Uwe Laverenz [EMAIL PROTECTED] writes: : [EMAIL PROTECTED] schrieb: : : Uwe, do you have any remote machines? I'm wondering what the correct : sequence would be to update and reboot them. : : I would suggest to do it this way: : : 1. make buildworld : 2. make kernel KERNCONF=YOURCONF : 3. *reboot* (with new kernel and old userland) Into single user... : 4. make installworld : 5. mergemaster : 6. *reboot* This is the order that's recommended in UPDATING since 3.something. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: signal 12's everywhere on Current with update this morning.
Sure. I can do that. Some structures in statfs changed size. So you need to rebuild and install your kernel before you update the world. The instructions in the handbook should work just fine. 1. make buildworld 2. make buildkernel KERNCONF=NAME_OF_KERNEL_FILE 3. make installkernel KERNCONF=NAME_OF_KERNEL_FILE 4. shutdown -r now 5. boot into single user mode 6. fsck -p 7. mount -u / 8. mount -a -t ufs 9. swapon -a 10. make installworld 11. mergemaster 12. reboot There are a couple ports that also need rebuilt. I've heard cfs and postfix mentioned. There could be more. If you don't have many ports, just rebuild them all (that's what I'm doing). If you are using portupgrade, it's easy (portupgrade -afR). Obviously this could take awhile. Richard Coleman [EMAIL PROTECTED] Edmund L. Wong wrote: Could someone bring me up to speed on this thread? I just joined current and I also updated this morning and have all kinds of issues. THanks, Ed --- Richard Coleman [EMAIL PROTECTED] wrote: Someone just needs to bring the build(7) man page up to date with the handbook. Also, I noticed that build(7) still lists the installmost build target. I believe that was removed. I would file a PR except that my man pages always suck. Richard Coleman [EMAIL PROTECTED] Brent Jones wrote: If this is true, perhaps the build man page should be updated. Here's what the man page has to say on the topic: The ``approved'' method of updating your system from the latest sources is: make buildworld make buildkernel KERNCONF=FOO make installkernel KERNCONF=FOO make installworld mergemaster After running these commands a system reboot is required... This gives the impression that you're safe running all the builds without rebooting, especially as the word approved is used. Brent On Nov 13, 2003, at 11:18 PM, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Uwe Laverenz [EMAIL PROTECTED] writes: : [EMAIL PROTECTED] schrieb: : : Uwe, do you have any remote machines? I'm wondering what the correct : sequence would be to update and reboot them. : : I would suggest to do it this way: : : 1. make buildworld : 2. make kernel KERNCONF=YOURCONF : 3. *reboot* (with new kernel and old userland) Into single user... : 4. make installworld : 5. mergemaster : 6. *reboot* This is the order that's recommended in UPDATING since 3.something. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] = edmund l wong assistant staff : mit lincoln lab cs/ece alumni : carnegie mellon [EMAIL PROTECTED] http://www.edmundlwong.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: signal 12's everywhere on Current with update this morning.
Andy Farkas wrote: Richard Coleman wrote: 1. make buildworld 2. make buildkernel KERNCONF=NAME_OF_KERNEL_FILE 3. make installkernel KERNCONF=NAME_OF_KERNEL_FILE 4. shutdown -r now 5. boot into single user mode 6. fsck -p 7. mount -u / 8. mount -a -t ufs 9. swapon -a 9.5 adjkerntz -i Yep, forgot that part. I keep all my system clocks on UTC so I never do this step when building world. 10. make installworld 11. mergemaster 12. reboot Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
problems with Intel pro/100 VE
I did a search on the FreeBSD web site, as well as a google search, but didn't see an answer to this. I apologize if this has been discussed before. I've tried to installing FreeBSD 4.8 and 5.1. But neither of these recognize my network card (Intel PRO/100 VE running on new Dell computer). Has something for this card been added after 5.1, or is this too new a card for anyone to have added the necessary code? Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: System freezes with radeon 9100 graphics card
Brad Knowles wrote: At 9:40 PM -0700 2003/08/23, Scott M. Likens wrote: Also please teach your email client to word wrap. That's nasty. According to your headers, you're using Ximian Evolution 1.4.4. According to his headers, he's running Mutt/1.5.4i. You tell me. When Microsoft started shipping mail clients that didn't wrap words by default, I was also pissed. But that was many moons ago (10 years maybe?). But at this point, anyone still using a mail client that doesn't know how to deal with this is living in the past. And no amount of complaining that this isn't what was intended by the RFCs is going to change this. This is just my humble opinion. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: status of nsswitch.conf in current?
I saw that. I guess my question is whether a default nsswitch.conf file will be checked into /etc and /usr/share/examples/etc, or whether it will be left empty? I would expect that if this capability was working, that a default nsswitch.conf would be checked into /etc. Many admins may not know the system has this capability unless they see a copy of nsswitch.conf in /etc. My next question is related to nss_ldap. Are there plans to add some type of credentials caching daemon to speed up use of LDAP (or other database) when using nsswitch.conf? If the hooks are there, I would be willing to work on this myself. Richard Coleman [EMAIL PROTECTED] Ruslan Ermilov wrote: On Fri, Aug 22, 2003 at 12:33:45AM -0400, Richard Coleman wrote: What is the status of nsswitch.conf in current? I noticed that there is a man page for nsswitch.conf. But there is no such file installed in /etc, nor is there an example copy in /usr/share/examples/etc. I just cvsup'ed tonight (Thursday) and built world. So, I'm up to date. Please see the ``Default source lists'' section of the nsswitch.conf(5) manpage that talks about this case. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: status of nsswitch.conf in current?
Having additional examples in /usr/share/examples/etc would also be nice. (Ideally, with a comment in /etc/nsswitch.conf.example pointing to those additional examples.) At the very least, a copy of the default nsswitch.conf should be in the examples directory.Since I didn't find an example there, I figured the facility was either not fully implemented yet, or broken (otherwise an example would be there). That's the reason I asked on the list in the first place. Since I'm pretty experienced with FreeBSD and it confused me, you can be sure it will confuse others. I do find Ruslan's logic here a bit peculiar, though. Having an nsswitch.conf with the default settings should only slow things down by the time needed to parse the file. Well-written parsers are very fast. I also feel that the logic that this will slow things down is a red herring. For many of the common cases (i.e. host name resolution by a remote DNS server) the amount of time to parse the nsswitch.conf will be minuscule relative to the amount of time necessary for to perform the lookup. I would love to know how much overhead parsing the nsswitch.conf adds to a local password lookup. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
status of nsswitch.conf in current?
What is the status of nsswitch.conf in current? I noticed that there is a man page for nsswitch.conf. But there is no such file installed in /etc, nor is there an example copy in /usr/share/examples/etc. I just cvsup'ed tonight (Thursday) and built world. So, I'm up to date. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
