Re: problem with kerberos startup and LDAP
On Sun, Nov 30, 2003 at 10:37:08PM -0800, Sean McNeil wrote: Hello All, I was having trouble with startup and kdc/kadmin5 failing. Turns out that they were trying to access a shared library in /usr/local/lib (libldap.so.2). Unfortunately, both were getting started before ldconfig. I added ldconfig to the REQUIRE: for kerberos and now all is well. What should be the correct solution? Let's see: What implementation of Kerberos? (Heimdal, MIT?) Installed as part of the base system, from the Ports Collection, or by hand? The correct solutions are: (a) Do not build Kerberos against OpenLDAP if you do not use LDAP functionality. (b) When building Kerberos, make certain that the linker flags include an appropriate setting for RPATH, e.g. `-rpath /usr/local/lib'. Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Need example file for nsswitch.conf in /usr/share/examples
On Sat, Nov 29, 2003 at 04:41:11PM -0500, Richard Coleman wrote:
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.
I won't be adding one for reasons already discussed on the list list
back in August (I think you started that thread, too, Richard)--- in
short I do not think it is needed and could even be harmful (if people
copy it to /etc/nsswitch.conf).
But, if someone has a set of *good* example configurations and they
are installed in share/examples/etc/nsswitch.conf.${description},
I certainly would not object. (e.g. nsswitch.conf.hesiod,
nsswitch.conf.ldap, and so on)
Cheers,
--
Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can we get rid of kerb5 redefining macros?
On Mon, Dec 01, 2003 at 09:47:04PM +0900, Hajimu UMEMOTO wrote: I made a patch for this. However, I forgot to sent it to Kerberos5 guy. Thanks! I'll see about getting it upstream. Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [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, dynamic vs. static
On Sat, Nov 29, 2003 at 02:01:02PM +0100, Matthias Andree wrote: Jacques A. Vidrine [EMAIL PROTECTED] writes: NSS and PAM do not overlap. I wonder how PAM gets system authentication information for pam_pwdb or pam_unix or how it's called today and on the pertinent system if not through NSS. Reimplementation of these passwd/shadow/whatever mechanisms? No, PAM uses the system directory services APIs (e.g. getpwnam(3) and similar). Those in turn use NSS, on NSS systems. Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [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
On Sat, Nov 29, 2003 at 02:45:24AM +0100, Dag-Erling Smørgrav wrote: Jacques A. Vidrine [EMAIL PROTECTED] writes: Interesting. Explain, please. (Maybe privately or in another thread; hate to keep this'n going.) Perhaps you mean that it is a design flaw that two APIs are required. If so, I happen to disagree; I think that the separation of directory services and authentication is appropriate and necessary. No, the two are essentially one. We just think they aren't because we've been brainwashed to think of users in terms of uids and gids and especially struct passwd, which deserves to die. By `the two', do you mean directory services and authentication? They are certainly not `essentially one'. But I suspect you know this and I am just misunderstanding your meaning. 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. I guess I think of it this way. If NSS had not been implemented `down in the mud' (inside getpw*, getgr*, gethostby*, etc.), then applications that used the UNIX directory service APIs would need to be re-written in order to utilize NSS. That's a lot of code to change for little benefit. PAM is different. Applications *had* to be re-written to utilize PAM, because previously there was no real authentication API, just crypt() and strcmp()--- obviously insufficient for many authentication methods :-) 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. If I understand you correctly, you believe that it would be possible to unite the NSS and PAM switches, so that they used the same configuration file, dynamic loading mechanisms, cascading, and so on. Sure, I think that's possible. There might even be some benefit, though probably not enough benefit to abandon PAM/NSS and go our own way. Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [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
On Mon, Dec 01, 2003 at 05:48:22PM +0100, Dag-Erling Smørgrav wrote: They are different issues, but in this context you can't discuss one without the other. Authentication doesn't work unless you have a user to authenticate. It makes no sense to separate them; you just end up duplicating a lot of concepts and code. Hmm, I disagree completely. :-) They can be separated and should be separated. Systems that mix them up are flawed. The confusion of the two are what *causes* the problem you bring up below (passwd(1)). Authentication simply names you. It is quite possible to be authenticated in some context and have absolutely no privileges or other information (``in a vacuum'', if you will). It is even useful in some cases: = `Junk' certificates = `Junk' Kerberos principals = A disabled account = A newly-created account More practically speaking, the mechanism by which you authenticate usually has no bearing on what you are authorized to do. This is the power of properly separating authentication and authorization: regardless of whether I authenticate by entering my password, inserting my smart card and PIN, or supplying a Kerberos ticket, my privileges will be the same [1]. Similarly, if the IT department moved from NIS to LDAP over the weekend, all my existing authentication tokens naturally still work. That's not to say that you *cannot* combine authentication and authorization, but they are naturally independent and different protocols and semantics are required for one and the other. RADIUS is a good example. It is quite difficult to properly support a variety of authentication mechanisms in RADIUS. Diameter addresses the issue by supporting a separate authentication protocol, EAP, which in turn allows for various authentication mechanisms generically. Also, is changing your password an authentication function or a directory function? I don't think you can answer either without answering both. I think it is strictly an authentication function. The change in your password has no affect on your UID, or your phone number, or in what ACLs your name appears in. I guess I think of it this way. If NSS had not been implemented `down in the mud' (inside getpw*, getgr*, gethostby*, etc.), then applications that used the UNIX directory service APIs would need to be re-written in order to utilize NSS. That's a lot of code to change for little benefit. Backward compatibility is fine, but NSS does not seem to export an API that we can use when we want to lift ourselves out of the mud, so we are forced to keep rooting around in it. What's an example of what you mean? The BSD nsswitch implementation has a generic nsdispatch(3) that allows for new applications, but I'm not sure that is what you mean. At any rate, it is not `NSS' proper, it is an implementation detail. One consequence of this (and of the artificial separation between NSS and PAM) is that passwd(1) doesn't work properly except in the simplest cases. It seems to me that this is a direct result of passwd(1) confusing authentication and authorization. Other than determining the default target user name from the current UID, passwd(1) needs only to invoke PAM interfaces to change your password for any authentication method that supports password changing. Of course this won't work for certain legacy, read-mostly `authentication methods' such as NIS or Hesiod that aren't supported by PAM. If I understand you correctly, you believe that it would be possible to unite the NSS and PAM switches, so that they used the same configuration file, dynamic loading mechanisms, cascading, and so on. Sure, I think that's possible. There might even be some benefit, though probably not enough benefit to abandon PAM/NSS and go our own way. Not to go our own way, no. There's the rub. It would have to be a reasonably wide effort; we'd need to get at least one major Linux distro to adopt the same infrastructure. Indeed, ``there's the rub'' :-) Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [1] Mostly. An application might require that you used a strong authentication method, to launch the nukes or something. :-) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problem with kerberos startup and LDAP
On Mon, Dec 01, 2003 at 10:10:20AM -0800, Sean McNeil wrote:
This was with Heimdal from an installation of -CURRENT. I am using LDAP
functionality, so option (a) below is not an option. Option (b) below
sounds more difficult than the change I made to /etc/rc.d/kerberos :)
I hadn't thought kerberos would get linked in such a manner, but now
that you mentioned it here is what it ended up using:
/usr/libexec/kdc:
libkrb5.so.7 = /usr/lib/libkrb5.so.7 (0x2807e000)
libhdb.so.7 = /usr/lib/libhdb.so.7 (0x280ba000)
libroken.so.7 = /usr/lib/libroken.so.7 (0x280ca000)
libasn1.so.7 = /usr/lib/libasn1.so.7 (0x280d8000)
libcrypto.so.3 = /lib/libcrypto.so.3 (0x280fe000)
libcrypt.so.2 = /lib/libcrypt.so.2 (0x28208000)
libcom_err.so.2 = /usr/lib/libcom_err.so.2 (0x28221000)
libldap.so.2 = /usr/local/lib/libldap.so.2 (0x28223000)
liblber.so.2 = /usr/local/lib/liblber.so.2 (0x28254000)
libc.so.5 = /lib/libc.so.5 (0x2826)
libsasl2.so.2 = /usr/local/lib/libsasl2.so.2 (0x28337000)
libssl.so.3 = /usr/local/lib/libssl.so.3 (0x2834a000)
libcrypto.so.3 = /usr/local/lib/libcrypto.so.3 (0x2837b000)
It only complained about libldap.so.2, so I would guess kerberos is
using the -rpath for the others?
Oh, you must be using `WITH_OPENLDAP'--- an option that I did not even
realize was available in the base system until I looked just now :-)
Yes, I believe the build is broken and I will correct it after the
code freeze. In the meantime, you might try the following patch and
rebuild the KDC (`make clean' first).
Cheers,
--
Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Index: kerberos5/Makefile.inc
===
RCS file: /home/ncvs/src/kerberos5/Makefile.inc,v
retrieving revision 1.19
diff -c -r1.19 Makefile.inc
*** kerberos5/Makefile.inc 18 Jul 2003 13:21:55 - 1.19
--- kerberos5/Makefile.inc 1 Dec 2003 18:21:23 -
***
*** 16,22
OPENLDAPBASE?=/usr/local
LDAPLIBS=-lldap -llber
LDAPCFLAGS=-I${OPENLDAPBASE}/include -DOPENLDAP=1
! LDAPLDADD=-L${OPENLDAPBASE}/lib ${LDAPLIBS}
.endif
.if exists(${.OBJDIR}/../../include)
--- 16,22
OPENLDAPBASE?=/usr/local
LDAPLIBS=-lldap -llber
LDAPCFLAGS=-I${OPENLDAPBASE}/include -DOPENLDAP=1
! LDAPLDADD=-L${OPENLDAPBASE}/lib -Wl,-rpath,${OPENLDAPBASE}/lib ${LDAPLIBS}
.endif
.if exists(${.OBJDIR}/../../include)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
NSS and PAM (was Re: NSS and PAM, dynamic vs. static)
[Threading intentionally broken.] On Sat, Nov 29, 2003 at 01:16:25AM +0100, Dag-Erling Smørgrav wrote: Jacques A. Vidrine [EMAIL PROTECTED] writes: NSS and PAM do not overlap. They are complimentary and one cannot do the job of the other. That is a bug in NSS, PAM or both. Interesting. Explain, please. (Maybe privately or in another thread; hate to keep this'n going.) Perhaps you mean that it is a design flaw that two APIs are required. If so, I happen to disagree; I think that the separation of directory services and authentication is appropriate and necessary. (BTW, I think you mean that they are complementary, not complimentary, although it is certainly true that some implementations of NSS and PAM are free) heh, Yes, that's a spell-o from which spell-check could not save me. Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [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, dynamic vs. static (was: 40% slowdown with dynamic /bin/sh)
On Wed, Nov 26, 2003 at 02:00:08AM +0100, Matthias Andree wrote: Matthew Dillon [EMAIL PROTECTED] writes: How much do you intend to use NSS for? I mean, what's the point of adopting this cool infrastructure if all you are going to do with it is make a better PAM out of it? The important thing is that NSS allows to plug modules such as LDAP or PostgreSQL for user base management. PAM is only halfway there and doesn't give libc et al. a notion of a user or group context (in spite of its account context), NSS does. One might discuss if PAM is really needed with NSS in place, but it's hard to think of a system without NSS and removing PAM now doesn't look right. NSS and PAM do not overlap. They are complimentary and one cannot do the job of the other. Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
On Mon, Nov 24, 2003 at 07:11:29PM -0800, Matthew Dillon wrote: You don't need dynamic loading to get nsswitch type functionality. You only need dynamic loading if nobody is willing to write an IPC model to get the functionality. It's really silly to create such a fundamental restriction on the binary because people are too lazy to build an IPC based mechanism. Matt, I'm not lazy. (Well, maybe I am, but that's not why I implemented NSS in the canoncial way instead of using IPC.) I've experimented with proxy-based solutions. Such solutions add a lot of complexity with little benefit. The primary NSS backends today are: NIS --- lightweight, proxy would just slow things down Hesiod --- lightweight winbindd --- lightweight (it implements its own proxy) nss_ldap --- could benefit IMHO, it makes more sense to write NSS modules that do their own proxying than to make things even more complicated in libc. Those that are lightweight don't carry extra baggage; those that do can implement proxying in the most efficient manner for that particular backend, e.g. some calls can be proxyed while others done in-process. You don't have to rewrite existing NSS modules so that they take into account that they are really serving multiple processes--- which usually means adding credentials management, locking, per-process state, and so forth to each NSS module. Or you could just create a whole new NSS API and call it something else and forget about support for existing NSS modules. Caching results (which is different than out-of-process implementations, the Linux nscd authors are just confused) does require a daemon, but this doesn't really complicate things. (I should get around to that someday :-) That said, I would not stand in the way of a well-thought out, well-written NSS implementation that attempts to proxy every get*() call over e.g. RPC. (Hmm, sounds like NIS to me. I guess that's partially explains why PADL.com's NIS-LDAP gateway is popular :-) Not only silly, but it seems to me that it also creates security issues. At least with a client/server model it is possible to isolate the authentication code to, for example, disallow exec(), filesystem operations, or the opening of any new files. Um, if you can't trust the authentication code, what can you trust? Furthermore, for many many many applications that use getpwnam(3) and so on, increased privileges are not needed or wanted. And if you *are* really talking about authentication code (and not directory services), then you need to get PAM to work in a statically linked world, also. (You can compile PAM statically today, but that means no 3rd-party modules. The same holds for NSS, of course.) The other huge advantage that IPC has over DLL is that you can switchout the backend mechanisms on a running system without killing and restarting anything other then he one service you want to switch out, and if it doesn't work right you can restart the old one or keep live as a fallback. When using the current NSS implementation, there is no need to kill/restart anything when you update /etc/nsswitch.conf. New modules are dynamically loaded, and any no-longer-referenced ones are unloaded. the IPC model is so much better then the DLL model for this sort of thing I don't understand why people are even arguing about it. Because the rest of us are stupid and lazy, remember? :-) Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
On Mon, Nov 24, 2003 at 10:06:12PM -0500, Andrew Gallatin wrote: How about Gordon's initial bootstone, which increased by 25%? http://docs.freebsd.org/cgi/mid.cgi?16091.44150.539095.704531 And I just did a make clean run in /usr/ports/archivers (by manually mv'ing a static and dynamic sh to /bin in turn): static: 96.63 real53.45 user39.27 sys dynamic: 112.42 real55.51 user51.62 sys The wall clock is bad (16% worse) and the system time is worse (31%). So.. 1) Microbenchmark:40% worse 2) Bootstone(*): 25% worse 3) Ports: 16% worse So can we just have a statically linked /bin/sh and get on with life? That seems to have the most impact. We can also expend our efforts to improve dynamic linking performance, since that will improve the performance of the other 99.9% of the universe. Users who REALLY REALLY need /bin/sh to support 3rd-party NSS modules in the mean time can build /bin/sh dynamically. Or we can have /usr/bin/sh as someone else suggested (most of the FreeBSD world's shell scripts--- which are what we *really* seem to be talking about--- already have #! /bin/sh). I prefer to keep as much of the world dynamic, both for dlopen support and for easier system patching. But I can also understand the desire to avoid a penalty for all those short but oft-run scripts. In any case, I'd really like to see a goal for 5.3-RELEASE that includes bringing dynamically-linked /bin/sh performance (*much*) closer to statically-linked /bin/sh performance. Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
On Mon, Nov 24, 2003 at 08:22:52PM -0600, David Leimbach wrote: Yep :). I feel like saying set the default to static and make the dynamic bins the option so the people who can't be bothered to compile their own system even though everyone I know does this for tuning purposes anyway can stop whining. But I won't say that. I feel we need to pressure to improve the performance of dynamic linking. This is not really different from anything else we do in -CURRENT: some things we have to throw out there before it is perfect, in order to reach critical mass. Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
On Tue, Nov 25, 2003 at 11:50:25AM -0800, Matthew Dillon wrote: Just not thinking out of the box, maybe. Matt, I'm talking about the de facto standard NSS, as found in Solaris and Linux; and now FreeBSD 5 [*] and soon NetBSD [**]. You are talking about some better mousetrap. The latter does not have any relevance to this thread, which is about dynamic linking in next release of FreeBSD. If you want to talk about FreeBSD 6.x and a better mousetrap, please go right ahead with a new thread here on freebsd-current or over on freebsd-arch. If you want to talk about the future of DragonFlyBSD, I'm sure there is an appropriate list for that--- this one ain't it. Parts of your message certainly seemed to describe what might be best for some other operating system. Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Side notes: [*] The actual APIs used by Solaris and Linux are *very* different; and the APIs used by FreeBSD are *somewhat* different from Linux. However, because the *core concepts* are the same--- dynamic loading, in-process modules--- portability issues are not much of a problem. [**] NetBSD doesn't support dynamic loading yet, but has had considerable influence on the FreeBSD implementation. NetBSD developers have indicated to me that they expect to bring in the FreeBSD changes so that there will be basically the same implementation on FreeBSD and NetBSD. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
On Tue, Nov 25, 2003 at 04:46:24PM +0200, Enache Adrian wrote: On Mon, Nov 24, 2003 a.d., Jacques A. Vidrine wrote: The application is broken. You must only check errno if you get an error indication from the library call. Sorry, but I don't see your point. I know when to check for errno. If you took the little illustrating program for a real life example of the use of errno, that's unfortunate :-) The problem is that the emulated/wrapped close from libc_r does not behave like the real one. libc_r is leaking some of its guts (the tricks it's doing with O_NONBLOCK, etc) in the interface. This is technically a bug. The fix was trivial. Hello Enache, My point was that this is not technically a bug. According to IEEE Std 1003.1-2001 aka the Single Unix Specification Version 3 (``SUSv3'') aka POSIX, an application must not examine and interpret `errno' unless the library gives an error indication. There are some functions--- strtol and family, sysconf, others--- that have unusual, errno-preserving behavior. These are described individually in the appropriate section of the standard. For these and only these, you can set errno to 0 and check it immediately after the function call to see whether an error has occurred. I believe that includes all functions described in ISO/IEC 9899:1999 (``C99''), as well as some described only in SUSv3. `close' is not a part of C99, nor is it attributed the `unusual', errno-preserving behavior in SUSv3. (By the way, this exact topic was discuss at some length by the the Austin Common Standards Revision Group this past summer.) Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
On Tue, Nov 25, 2003 at 12:39:11PM -0800, Matthew Dillon wrote: My original opinion still stands... you guys are using this issue as an excuse to basically do away with static binaries, rather then fixing the real problem which is an inability to dynamically load modules in a static binary. No, it is one of the issues that have been pushing FreeBSD (and most other modern UNIX systems, it seems) towards more dynamically linked components. The other issues have also been discussed on this list recently and in the pass. I'm not sure why this one draws such interest. (I participate in this thread only because I feel like I know a thing or two about the NSS details.) Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
On Sun, Nov 23, 2003 at 04:14:08PM +0200, Enache Adrian wrote:
$ cc close.c -o close ./close
0
0
$ cc close.c -lc_r -o close ./close
0
25
$ cat close.c
#include errno.h
main()
{
int fd = open(/dev/null, 1);
printf(%d\n, errno);
close(fd);
printf(%d\n, errno);
}
This confuses rather badly applications which assume errno is meaningful.
The application is broken. You must only check errno if you get an
error indication from the library call.
URL:http://www.opengroup.org/onlinepubs/007904975/functions/errno.html
IEEE Std 1003.1, 2003 Edition says, in part:
``The value of errno should only be examined when it is indicated to
be valid by a function's return value.''
Cheers,
--
Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [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
[cc: dropped] I suppose I should comment on this thread, since I'm closely related to at least two of the rationales mentioned for moving towards an all-dynamically-linked system. (I would prefer to stay out of this thread. In my mind we've had all these arguments in various forums months ago and the issue was put to rest.) On Tue, Nov 18, 2003 at 05:06:06PM -0700, Scott Long wrote: 2. NSS support out-of-the-box: Again, this is a user-experience issue in that forcing NSS users to recompile world was seen as a potential roadblock to them. Some followups mentioned that a different implementation of NSS would not require dynamically linked binaries. This is technically true. Certainly, I explored that avenue. But practical considerations made that alternative a poor choice. Supporting NSS really also means supporting (in as much as possible) the existing base of NSS modules. These modules were all designed to be loaded by libc and invoked in-process. (nscd doesn't do what some seem to think it does, and in practice it is not well-loved.) Existing NSS modules also shaped some other decisions that I made (such as API entry points and thread awareness or lack thereof). Breaking with the fundamental designs of NSS as found on Solaris and Linux means practically starting from scratch when `porting' NSS modules. I'm sure someone more clever and with more time could make it work out-of-process. Based on my experience, I think the result would be overengineered. *shrug* Finally, if we could call `dlopen' from statically-linked binaries, this wouldn't be an issue. I'd really like to see dlopen support for statically-linked binaries, for NSS and many other applications. 3. Binary security updates: there is a lot of interest in providing a binary update mechanism for doing security updates. Having a dynamic root means that vulnerable libraries can be updated without having to update all of the static binaries that might use them. Actually, not only binary security updates but any security updates, or bug fixes for that matter. If there is a bug in a library, fixing that bug on your system is much more straightforward if everything is dynamically linked. It is much easier to rebuild libc or libcrypto and restart applications then to have to go through an entire `make world'. It can be hard for many administrators to avoid `make world', because it is not always easy to ascertain what applications are using what APIs and libraries. There's been a lot of talk about performance, but for my environment all the workhorse applications are already dynamically linked. I'd guess that is the case for most FreeBSD users. And of course, most FreeBSD binaries--- in the base system, in ports, and commercially available--- are already dynamically linked. For the minority of users that it actually has a performance impact (show of hands?), of course they are sophisticated enough to build the affected binaries statically. Unless we are talking about /bin/sh, they probably already have to go through special measures to get a statically linked binary. Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kerberos5 === kerberos5/lib/libhdb
On Fri, Oct 10, 2003 at 06:44:25PM +0700, Dikshie wrote: === kerberos5 cd /usr/src/kerberos5; /usr/obj/usr/src/make.i386/make buildincludes; /usr/obj/usr/src/make.i386/make installincludes === kerberos5/doc === kerberos5/lib === kerberos5/lib/libroken ./make-roken tmp.h ; if [ -f roken.h ] cmp -s tmp.h roken.h ; then rm -f tmp.h ; else rm -f roken.h; mv tmp.h roken.h; fi === kerberos5/lib/libvers === kerberos5/lib/libasn1 ./asn1_compile /usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/k5.asn1 krb5_asn1 test -e /usr/obj/usr/src/kerberos5/lib/libasn1/asn1_err.et || ln -sf /usr/src/kerberos5/lib/libasn1/../../../crypto/heimdal/lib/asn1/asn1_err.et compile_et asn1_err.et === kerberos5/lib/libhdb make: don't know how to make hdb_asn1.h. Stop *** Error code 2 Stop in /usr/src/kerberos5/lib. *** Error code 1 thanks ! My g00f ... fixed, thanks! Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [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: can't find kernel source tree error when building the kernel.
On Fri, Oct 03, 2003 at 09:02:19PM +0300, Ruslan Ermilov wrote: Maybe now it will be more obvious why I thought that upgrade_checks should always be done, for all standard src/Makefile targets. Currently, you either need to upgrade your /usr/bin/make binary manually, or to use this command from /usr/src: make buildkernel -DALWAYS_CHECK_MAKE ... with up-to-date tools/regression/usr.bin/make/ and usr.bin/make/ sources. I don't think the original poster was building his kernel with src/Makefile targets. I believe he was doing it the old-fashioned way: manual config, make depend, make kernel. Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: can't find kernel source tree error when building the kernel.
On Fri, Oct 03, 2003 at 07:57:51PM +0300, Clau wrote:
hello,
i just downloaded via cvsup the latest kernel for freebsd 5.1.
i had a problem with it, more exactly when i did a make depend
it stopped at some place, and gave me this error:
can't find kernel source tree
i fixed this by modifying this piece of code from /usr/src/sys/conf/kmod.mk
(it starts with line 167 in the file)
.for _dir in ${.CURDIR}/../.. ${.CURDIR}/../../.. /sys /usr/src/sys
.if !defined(SYSDIR) exists(${_dir}/kern/)
SYSDIR= ${_dir}
.endif
.endfor
.if !defined(SYSDIR) || !exists(${SYSDIR}/kern/)
.error can't find kernel source tree
.endif
i removed the last / from /kern/ and now it seems it can find the
directory.
i don't know if this is a general problem, or it is just in the case of
my system.
How are you building the kernel? Are you using `make buildworld' first
and then `make buildkernel' (or `make kernel')?
Cheers,
--
Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal
[EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing -pthreads (Re: ports and -current)
[Mostly trying to stay out of this thread, but I must comment at least on this point.] On Wed, Sep 24, 2003 at 11:01:01AM -0400, Daniel Eischen wrote: On Wed, 24 Sep 2003, Scott Long wrote: Daniel Eischen wrote: o Allows shared libraries (Qt, GTK, OpenGL, etc) to be built that are not dependent on a particular threads library, but will use whatever threads library the application uses (i.e., you want mplayer to use libpthread and ogle to use libthr). I'm a big advocate of using libmap to deal with this. It isn't clear that libmap can deal with libraries that are linked to one specific threads library, and how libmap'd applications work. If mplayer is libmap'd to libthr, ogle is libmap'd to libpthread, and both are linked to libGL which is linked to libc_r, what happens? At the least, -pthread should be a NOOP when building shared and dynamic. While libmap is a very neat hack and very useful, it is indeed a hack and I do not think it should be the primary method of determining what libraries to load. The mere existance of a libmap.conf file means additional file opening and parsing every time a dynamically linked executable is loaded; as well as one or more string searches/substitutions for every dynamic object name that rtld encounters (not just thread libraries). I believe that we should be able to make decisions at link time and at run time. At link time, either (a) I want *this* threaded library damnit, or (b) choose a threaded library at run time, with (b) being the default. Choosing (a) probably allows you to shoot your foot by mixing threading libraries, but it may also allow you to use `extensions' that one threading library might provide but not another. At run time (if (b) was chosen at link time): use *this* threaded library. By what mechanism? I imagined that there could be a library (say libpthread :-P) that made the decision and loaded the *real* threading library and forwarded or fixed-up thread-related functions. A degenerate-but-simple implementation might be a symlink. This seems to be more-or-less what GCC developer Loren James Rittle [EMAIL PROTECTED] had in mind when he posted the following suggestion to freebsd-threads some weeks back: Thank you for considering these words. BTW, wouldn't it be cooler if (example only): -pthread (whatever the system default) -pthread=1 (1 process, aka -lc_r) -pthread=1:1 (1 process per thread, aka -lthr) -pthread=M:N (M threads in N processes, aka -lkse) -pthread=late/weak (perhaps not good ELF form, link against a stub to which all POSIX thread libraries on FreeBSD must conform, do not record the dependency ala FreeBSD4 default for -lc; or that does it in a weak manner en mass such that binding is deferred to the final selection made at a final link time) Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing -pthreads (Re: ports and -current)
On Wed, Sep 24, 2003 at 10:27:29AM -0500, Jacques A. Vidrine wrote: At link time, either (a) I want *this* threaded library damnit, or (b) ^^^ that one threading library might provide but not another. As an aside, apparently I couldn't (or at least didn't) decide between `threaded library' and `threading library'. I wasn't trying to make some subtle distinction here :-) Probably I should have said `thread library' throughout. Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Release Engineering Status Report
On Tue, Sep 16, 2003 at 08:43:00AM -0400, David Rhodus wrote: Right, say if still the OpenSSH did or still comes out to be real. Ops, now thats right, we don't have 3.6.1 in STABLE, why ? It was released on April 1, does that not give one enough time to merge this in ? Merging new versions of software into the security branches is not what I really want to do. In general, I'll just backport the fix. In the past, we *have* merged new versions, but in hindsight this was usually a mistake. Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Release Engineering Status Report
On Tue, Sep 16, 2003 at 09:47:44PM -0400, David Rhodus wrote: On Tuesday, September 16, 2003, at 11:54 AM, Dag-Erling Smørgrav wrote: Is there a specific problem with OpenSSH 3.5 which requires an update to 3.6.1? Or do you just want me to update it to make the numbers look pretty on your screen? Umm, yeah, so after today are we going to get a new import into RELENG_4 before 4.9 is pushed out the door ? Hell no. :-) Frankly, OpenSSH 3.7.x will require quite a bit of testing and integration before it is even fit for -CURRENT. Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading to FreeBSD 5.1
On Mon, Sep 15, 2003 at 11:18:24PM +0300, Ruslan Ermilov wrote: You mean you upgrade to RELENG_5_1? Beware that this branch is currently not buildable: libpthread build is broken. Eh? By `this branch' you mean RELENG_5_1? How is it broken? If there is a problem (I don't know of any --- it built after I made the commits for the last security advisory), it is critical to fix it. -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [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?
On Fri, Aug 22, 2003 at 11:15:01AM -0700, Tim Kientzle wrote: On the other hand, having /etc/nsswitch.conf.example would a) Advertise the existence of nsswitch capabilities in an obvious place where people new to FreeBSD would see it. b) Document the defaults. c) Not slow anything down. d) Serve as an example and template for people just getting started.. There is no `default nsswitch.conf' mostly because it would have to be kept in sync with the *actual* defaults as implemented in libc. The nsswitch.conf(5) man page fulfills (a)-(d). That _is_ what documentation is for, after all. Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any patch for ICMP in a jail?
On Tue, Aug 05, 2003 at 03:55:55AM -0700, Terry Lambert wrote: Through the credential passing? I thought that wasn't reliable for this type of thing. Specifically, the jail would be in an untrusted protection domain; if you just accepted the credential blindly, then anyone could be root in the jail, and you could not trust it. If you didn't accept it blindly, then regular root loses existing functionality. I'm pretty sure that, at least the last time I looke at it, the credential passing code didn't pass information about jail status. [deletia] Sorry, you are right. Despite the subject line, I wasn't thinking of jails at this point, but just of removing the setuid bit from ping. Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any patch for ICMP in a jail?
On Mon, Aug 04, 2003 at 10:53:03AM -0700, Terry Lambert wrote: You would either lose or overexpose root-restricted functionality, such as flood-ping. Eh? Why? pingd can know your credentials. Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing gcc 3.3 compile failures -- fix for net/netsaint-plugins
On Tue, Jul 22, 2003 at 02:26:08PM +0200, Simon Barner wrote: --- plugins/check_by_ssh.c.orig Mon Apr 23 09:43:11 2001 +++ plugins/check_by_ssh.cTue Jul 22 05:05:52 2003 @@ -191,7 +191,7 @@ if (commands1) remotecmd=strscat(remotecmd,;echo STATUS CODE: $?;); - if (strlen (remotecmd) = 1) + if (remotecmd==NULL) usage (No remotecmd\n); comm = ssprintf(comm,%s %s '%s',comm,hostname,remotecmd); This looks like more than a fix for a `compile failure'. The replacement code has different semantics than the new code. What is the `compile failure' that was being fixed here? Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing gcc 3.3 compile failures -- fix for net/netsaint-plugins
On Wed, Jul 23, 2003 at 01:57:56AM +0200, Simon Barner wrote: --- plugins/check_by_ssh.c.orig Mon Apr 23 09:43:11 2001 +++ plugins/check_by_ssh.cTue Jul 22 05:05:52 2003 @@ -191,7 +191,7 @@ if (commands1) remotecmd=strscat(remotecmd,;echo STATUS CODE: $?;); - if (strlen (remotecmd) = 1) + if (remotecmd==NULL) usage (No remotecmd\n); comm = ssprintf(comm,%s %s '%s',comm,hostname,remotecmd); This looks like more than a fix for a `compile failure'. The replacement code has different semantics than the new code. What is the `compile failure' that was being fixed here? I don't know, either. This patch was part of the port before I touched it [1]. Oh, well nevermind! I thought this was a new patch to deal with `compile failures'. Cheers! Perhaps one should write if ((remotecmd==NULL) || (strlen (remotecmd) = 1)) to be on the safe side? Maybe. The original submittor might recall. Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing gcc 3.3 compile failures -- fix for math/freefem
On Sat, Jul 19, 2003 at 05:05:39AM +0200, Simon Barner wrote:
--- freefem/fem/femDisk.cpp.orig Sat Jul 19 04:09:32 2003
+++ freefem/fem/femDisk.cpp Sat Jul 19 04:13:43 2003
@@ -95,7 +95,7 @@
char *result = 0;
int dummy;
-ifstream fin( path );
+std::ifstream fin( path );
if ( fin.fail() )
{
[... 405 lines deleted ...]
A much smaller patch could be produced with
using namespace std;
as appropriate.
Have you checked with the upstream author to see which approach is
likely to be rolled into the distribution?
Cheers,
--
Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal
[EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc-3.3 issues
[cc: list trimmed]
On Fri, Jul 18, 2003 at 10:32:51AM +0200, Michael Nottebrock wrote:
I've tried to come up with a less obscure testcase:
#include string
#include iostream
using namespace std;
int main ()
{
string astring=Hello World;
cout astring endl;
}
Now, if I compile this on 5.1-RELEASE with
c++ -Wnon-virtual-dtor -Wno-long-long -Wall -pedantic -W -Wpointer-arith
-Wmissing-prototypes -Wwrite-strings -DNDEBUG -DNO_DEBUG -O -pipe
-mcpu=pentiumpro -fno-check-new -L/usr/local/lib -I/usr/local/include
-I/usr/local/include -I/usr/X11R6/include -D_GETOPT_H -o helloworld
helloworld.cc
I get a plethora of warnings:
In file included from /usr/include/g++/memory:55,
from /usr/include/g++/string:48,
from helloworld.cc:1:
/usr/include/g++/bits/stl_alloc.h:979: warning: ISO C++ forbids the use of `
extern' on explicit instantiations
/usr/include/g++/bits/stl_alloc.h:980: warning: ISO C++ forbids the use of `
extern' on explicit instantiations
/usr/include/g++/bits/stl_alloc.h:981: warning: ISO C++ forbids the use of `
extern' on explicit instantiations
/usr/include/g++/bits/stl_alloc.h:981: warning: ISO C++ forbids the use of `
extern' on explicit instantiations
/usr/include/g++/bits/stl_alloc.h:981: warning: ISO C++ forbids the use of `
extern' on explicit instantiations
[and many, many more]
but it will compile. If I omit -pedantic, none of these warnings occur. The
thing is, in -CURRENT with the new gcc, all these warnings for some reason
become errors. The other thing is, if I try this with with a ports-compiled
g++32 on 4-STABLE, I don't get warnings at all, no matter if -pedantic is
specified or not.
So here's the questions for the experts:
- Why errors instead of warnings?
- Why do gcc's own bits seem to not conform to some kind of standard that it
tries to adhere to in 5-CURRENT but not in 4-STABLE?
- Who's to blame?
I haven't looked recently, but I seem to recall that the STL and other
C++ header bits that we install in /usr/include are from an older GCC
release than the compiler. On my pre-GCC 3.3 -CURRENT system:
System compiler:
% g++ -c -Wall -pedantic hello.cc
many warnings
GCC 3.2 from ports:
% g++32 -c -Wall -pedantic hello.cc
no warnings
GCC 3.3 from ports:
% g++33 -c -Wall -pedantic hello.cc
no warnings
I also recall lots of missing `typename's in the system headers that were
resolved in the actual GCC distribution.
Alexander, do the STL headers et. al. get updated with the rest of the
compiler chain?
Cheers,
--
Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal
[EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc-3.3 issues
[For some reason I haven't seen Alexander's post yet, so I'm mixing replies here.] On Fri, Jul 18, 2003 at 06:12:10PM +0200, Michael Nottebrock wrote: On Friday 18 July 2003 17:37, Alexander Kabaev wrote: On Fri, 18 Jul 2003 10:33:58 -0500 Jacques A. Vidrine [EMAIL PROTECTED] wrote: I also recall lots of missing `typename's in the system headers that were resolved in the actual GCC distribution. Alexander, do the STL headers et. al. get updated with the rest of the compiler chain? Yes. But libstdc++ itself lags a bit behind GCC features. The reason why GCC ports are not reporting any errors is because by default GCC suppresses warnings from system headers, and C++ headers are considered system. We disable this suppression in imported compiler. Ah, that didn't occur to me. Duh. I guess we shall just wait for libstdc++ to catch up --- it looks like at least some of these issues are already fixed in GCC CVS. I guess the next question is whether this is fixable, maybe even by enabling said supression, at least for a short while. It seems the better fix than to go and remove -pedantic from all the helloworlds that may linger in the ports-tree. Even when libstdc++ is updated, we'll still be left with warnings from C-derived headers, such as the `long long' stuff. That should be fixable in some other fashion, but such discussion probably belongs on [EMAIL PROTECTED] Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: warning: inlining failed
On Fri, Jul 18, 2003 at 12:18:14PM -0700, Nate Lawson wrote: Warner mentioned this was due to the gcc import. Nearly every part of the kernel that uses newbus or buf.h prints out lots of warnings. Can someone see about fixing this, whether it's by fixing our headers or build flags or gcc itself? I've already wasted a few reboot cycles because valid warnings were lost in the crowd. cc -O -pipe -mcpu=pentiumpro -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -I/usr/include -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /home/src/sys/modules/ext2fs/../../gnu/ext2fs/ext2_vfsops.c /home/src/sys/gnu/ext2fs/ext2_vfsops.c: In function `compute_sb_data': @/sys/buf.h:281: warning: inlining failed in call to `BUF_LOCK' /home/src/sys/gnu/ext2fs/ext2_vfsops.c:496: warning: called from here /home/src/sys/gnu/ext2fs/ext2_vfsops.c: In function `ext2_unmount': @/sys/buf.h:281: warning: inlining failed in call to `BUF_LOCK' /home/src/sys/gnu/ext2fs/ext2_vfsops.c:774: warning: called from here @/sys/buf.h:281: warning: inlining failed in call to `BUF_LOCK' /home/src/sys/gnu/ext2fs/ext2_vfsops.c:780: warning: called from here @/sys/buf.h:281: warning: inlining failed in call to `BUF_LOCK' /home/src/sys/gnu/ext2fs/ext2_vfsops.c:784: warning: called from here Does `-finline-limit=1200' (or bigger) help? I think GCC 3.3 added a warning for when inline functions generated `a lot' of instructions. In such a case, the function is not inlined. I believe this also happened with GCC 3.2, but it just didn't normally tell you about it. Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Undefined symbol getpwuid_r
[Sorry for delayed reply. I'm offline mostly lately.] On Thu, May 22, 2003 at 12:09:06PM +, David Leimbach wrote: On Thursday, May 22, 2003, at 03:53 AM, CARTER Anthony wrote: Hi, Just done a buildworld and installworld from yesterdays CVSUp (today, 22nd, 10:51am GMT+1). However, whenever I launch ymessenger now I get: /usr/libexec/ld-elf.so.1: /usr/local/lib/libglib12.so.3: Undefined symbol getpwuid_r Has anyone got an idea about this? [snip] If any further info is required just let me know. Have you recompiled the ymessenger code? It sounds as if some .so got replaced from an old compile and the code should no longer link if you rebuild it. The new NS stuff Jacques is working on most likely has caused this. It looks as if you may just need a rebuild of ymessenger. I don't think it is my fault :-) ymessenger is a binary port. It is linked against libc.so.4 (IIRC), which does not have getpwuid_r. Therefore, when ymessenger loads libglib12.so.3 (which was built against the newer libc.so.5), glib cannot find getpwuid_r in libc.so.4 (naturally). If getpwuid_r hadn't gotten you, something else probably would have :-) Basically, ymessenger can't really run on later versions of FreeBSD. It is dynamically linked against 12 libraries (besides libc.so.4), many of which have had ABI changes. I had a need to run ymessenger on FreeBSD 5 several weeks ago. In order to do so, I had to go back to old 4.5 CDs and extract libglib, libgtk, and so on into a special environment just to run ymessenger. You are better off running some other client, e.g. GAIM. But, if you insist: WARNING: This could have any effect, including but not limited to data loss, hair loss, self-esteem issues, deforestation, defenestration, etc. etc. By breathing, you agree to hold me harmless due to any of these effects and any other effects directly, indirectly, or not caused by following these directions or reading this message. Download URL: http://people.freebsd.org/~nectar/ymessenger-hack.tgz and extract it somewhere (BUT NOT IN YOUR ROOT DIRECTORY) and run it as shown. % mkdir $HOME/ymessenger % cd $HOME/ymessenger % tar zxvf /path/to/ymessenger-hack.tgz % env LD_LIBRARY_PATH=$PWD/usr/local/lib ./usr/local/bin/ymessenger.bin Someone with time on hand should update the ymessenger port to install the dependent libraries, too. *shrug* Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Plea for base system trim
On Wed, Mar 05, 2003 at 09:54:13AM -, Subscriber wrote: Having just done two rebuilds for recent OpenSSL and sendmail vulnerabilities, I was surprised to discover that building the port of apache13-modssl required the build of a port version of OpenSSL when I had the most updated (4.7) base system with OpenSSL in it!. I hate having two versions installed; it makes me fear that there will be problems caused by the wrong version being used. You are right to hate having two versions installed --- it is pointless in most cases. Please complain to the apache+mod_ssl and openssl port maintainers. It sounds to me like they are doing something very wrong. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
On Wed, Mar 05, 2003 at 08:54:28AM -0800, Brooks Davis wrote: At least in the case of net/net-snmp the problem is that the shared lib version of the openssl port was bumped when the base wasn't which screws up the dependencies. :-( That's part of the problem. The port bumped the shared library version, even though it installed ABI-compatible library. Moreover, it bumped it to a new version number that was only 1 higher, almost designed to cause trouble :-) If all OpenSSL-using ports used `-rpath', then this wouldn't be a problem. But that is kind of a burden. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Kerberos IV exiting tree for 5.1-RELEASE
Hello Gentlefolk, In the next couple of weeks, I will be removing Kerberos IV from -CURRENT. I will also be re-organizing the Kerberos 5 bits so that the utilities have their `normal' names (e.g. `kinit' rather than `k5init') and replacing Kerberos 4 support with Kerberos 5 support in applications so far as that is possible (e.g. TELNET, cvs). For those of you who do use Kerberos IV, I would appreciate it very much if you could try the security/krb4 port. If you run into trouble or have suggestions, please let me know. Better yet, send patches for the port! In fact, if you are a committer that uses Kerberos IV, please consider maintaining the security/krb4 port. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OpenSSL should define OPENSSL_THREADS?
On Mon, Feb 24, 2003 at 09:58:21PM -0500, Craig Rodrigues wrote: Hi, I ran a cvsup of -CURRENT a few days ago. I have some code which assumes that OPENSSL_THREADS is defined if the OpenSSL version is greater than 0.9.7: #define OPENSSL_THREAD_DEFINES #include openssl/opensslconf.h #include openssl/opensslv.h #if OPENSSL_VERSION_NUMBER 0x0090700fL # if !defined(THREADS) # error Thread support not enabled # endif #else # if !defined(OPENSSL_THREADS) # error Thread support not enabled # endif #endif Should the OpenSSL in FreeBSD be defining OPENSSL_THREADS? I think you may be right. OpenSSL 0.9.7's out-of-the box configure creates an opensslconf.h that would define OPENSSL_THREADS on FreeBSD. Mark supplied the opensslconf.h's that are used in the FreeBSD build ... let's see if this is intentional or not. [cc'd] Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gethostbyname_r and realpath_r (FreeBSD or Linux for your MySQL Server)
On Sat, Feb 22, 2003 at 11:23:55AM +0100, Martin Blapp wrote: Many of you know that we still do not have threadsafe versions of gethostbyname and realpath. There are some patches around since a while. Nobody did commit them. Is someone working on this ? I am working on those interfaces that go through nsdispatch (e.g. gethostbyname_r but not realpath_r). Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: memset prototype changed?
On Tue, Feb 18, 2003 at 12:01:29PM +0100, Dag-Erling Smorgrav wrote: Kris Kennaway [EMAIL PROTECTED] writes: http://bento.freebsd.org/errorlogs/i386-5-latest/netatalk-1.6.0_1,1.log The code that fails to compile is blatantly wrong: memset(schedule, 0, sizeof(schedule)); I wouldn't say `blantantly'. The expressions `schedule' and `schedule' are equivalent when `schedule' is an array type. I'd call it `ignoring an idiom'. Anyway, with libdes or OpenSSL 0.9.7, the type of `schedule' would have been an array. With OpenSSL = 0.9.7, the type of `schedule' is a struct. This port uses des.h, which we have as a symlink to openssl/des.h (ugh, I'd better remove that, too). If that include is replaced with e.g. #ifdef HAVE_OPENSSL #define OPENSSL_DES_LIBDES_COMPATIBILITY #include openssl/des.h #else #include des.h #endif things will be fine. -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: memset prototype changed?
On Tue, Feb 18, 2003 at 10:10:41AM -0800, Kris Kennaway wrote:
On Tue, Feb 18, 2003 at 12:47:35PM +0100, Richard Nyberg wrote:
On Tue, Feb 18, 2003 at 12:01:29PM +0100, Dag-Erling Smorgrav wrote:
Kris Kennaway [EMAIL PROTECTED] writes:
http://bento.freebsd.org/errorlogs/i386-5-latest/netatalk-1.6.0_1,1.log
The code that fails to compile is blatantly wrong:
memset(schedule, 0, sizeof(schedule));
I think this is due to the openssl upgrade.
DES_key_schedule was an array but is now a struct.
You would have to something like this to make it work now:
memset(schedule, 0, sizeof(schedule));
Could you please submit a patch to the maintainer?
Actually, this works since the port does -I/usr/include/openssl:
Index: Makefile
===
RCS file: /home/ncvs/ports/net/netatalk/Makefile,v
retrieving revision 1.48
diff -c -c -r1.48 Makefile
*** Makefile5 Jan 2003 23:42:00 - 1.48
--- Makefile18 Feb 2003 18:39:46 -
***
*** 23,28
--- 23,29
.endif
USE_BZIP2=yes
+ CONFIGURE_ENV+= CPPFLAGS=-DOPENSSL_DES_LIBDES_COMPATIBILITY
CONFIGURE_ARGS+= --with-tcp-wrappers \
--with-pkgconfdir=${PREFIX}/etc
.if defined(WITH_PAM)
(MAINTAINER cc'd)
Cheers,
--
Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/
NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos
[EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: memset prototype changed?
On Tue, Feb 18, 2003 at 08:55:02PM +0100, Dag-Erling Smorgrav wrote: Jacques A. Vidrine [EMAIL PROTECTED] writes: On Tue, Feb 18, 2003 at 12:01:29PM +0100, Dag-Erling Smorgrav wrote: The code that fails to compile is blatantly wrong: memset(schedule, 0, sizeof(schedule)); I wouldn't say `blantantly'. The expressions `schedule' and `schedule' are equivalent when `schedule' is an array type. ...but Key_schedule is an opaque type, so it is not correct to assume it's an array. You won't get much argument from me about that. Nonetheless, lots of code `knows' that it is `unsigned char[8]' (it _is_ DES, after all, where all the keys and operations are on 64 bits). Unfortunately, some of these practices were extended to the triple-DES interfaces as well... Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/lib/libc/stdlib rand.c
On Mon, Feb 17, 2003 at 04:40:48PM +1100, Tim Robbins wrote: I disagree. It's safe to use rand() in games and in certain kinds of simulations when you don't care that the distribution isn't quite uniform, Safe, maybe. But I think it still shouldn't be used. See my posting of two years ago: URL: http://groups.google.com/groups?selm=97b83t%2414q3%241%40FreeBSD.csie.NCTU.edu.twrnum=1 BTW, I don't care if linking a program with rand() gives an obnoxious warning or not. Just pointing out that rand() is less useful than it might seem. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Compiling with high optimization?
On Sat, Feb 08, 2003 at 05:23:01PM -0800, Terry Lambert wrote: The compiler didn't complain when he checked it before committing it because optimization was off by default; it should have complained, e.g.: Is that really what you meant? I don't believe it has anything to do with optimization; rather, it is to do with lack of `warning' flags. For example, if you build libc with WARNS=5 (so as to get the `-Wuninitialized' flag), then you get this warning. x.c:9:warning: `foo' might be used uninitialized in this function Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any chance of getting these OpenSSL warnings quieted?
On Sat, Feb 08, 2003 at 04:39:13PM -0800, David O'Brien wrote: cc -pipe -O -march=athlon -D_IEEE_LIBM -D_ARCH_INDIRECT=i387_ -c /FBSD/src/lib/msun/src/e_gammaf_r.c -o e_gammaf_r.o In file included from /FBSD/obj/FBSD/src/secure/lib/libcrypto/openssl/e_os2.h:56, from /FBSD/obj/FBSD/src/secure/lib/libcrypto/openssl/symhacks.h:58, from /FBSD/obj/FBSD/src/secure/lib/libcrypto/openssl/crypto.h:78, from /FBSD/obj/FBSD/src/secure/lib/libcrypto/openssl/bio.h:67, from /FBSD/obj/FBSD/src/secure/lib/libcrypto/openssl/err.h:68, from /FBSD/src/crypto/openssl/crypto/cpt_err.c:62: /FBSD/obj/FBSD/src/secure/lib/libcrypto/openssl/opensslconf.h:177:1: warning: OPENSSL_NO_KRB5 redefined /FBSD/src/crypto/openssl/crypto/cpt_err.c:1:1: warning: this is the location of the previous definition Yes, I'll eliminate these today. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Compiling with high optimization?
On Sun, Feb 09, 2003 at 03:17:12PM +0100, Erik Trulsson wrote:
On Sun, Feb 09, 2003 at 08:03:57AM -0600, Jacques A. Vidrine wrote:
On Sat, Feb 08, 2003 at 05:23:01PM -0800, Terry Lambert wrote:
The compiler
didn't complain when he checked it before committing it because
optimization was off by default; it should have complained, e.g.:
Is that really what you meant? I don't believe it has anything to
do with optimization; rather, it is to do with lack of `warning'
flags. For example, if you build libc with WARNS=5 (so as to get the
`-Wuninitialized' flag), then you get this warning.
x.c:9:warning: `foo' might be used uninitialized in this function
Some warnings are not generated unless you compile with optimization
on. The reason for this is that to generate some of the warnings (for
example about uninitialized variables) you need to do some dataflow
analysis and gcc only does this when optimizing.
Take for example this little program:
#include stdio.h
int main(void)
{
int a;
printf(%d\n,a);
return 0;
}
When compiled using 'gcc -O0 -Wall' no warnings are generated. When
compiled with 'gcc -O1 -Wall' you get a warning that 'a' might be used
uninitalized. (This is the case for gcc 2.95.x at least. I believe the
situation is the same with gcc 3.x)
Ah, I see. Yes, it is the case with gcc 3.x.
cc1: warning: -Wuninitialized is not supported without -O
I don't think I ever knew that.
I should have tried it before posting, but the comment that the
problem was that `optimization was off by default' threw me --- it is
ON by default.
Cheers,
--
Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/
NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos
[EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: tmpfile breakage on setuid executables
On Wed, Feb 05, 2003 at 02:59:15PM -0800, Terry Lambert wrote: Terry Lambert wrote: We need to know how we think it's supposed to work, not how you think it's supposed to work to determine if the error is in the code OR in the fact some old bug was fixed going from 4.7-5.0, and the fix is biting you, OR it's a real bug. For anyone who cares: Additional information was provided off-list. The problem was indeed that setuid(geteuid()); was missing from the program. Apparently, there was a bug fixed in 4.7 - 5.0, where the effective UID was being tested instead of the real UID. This is probably something that someone should MFC. Really? I just took a quick look at this, but I have to shove off for now. In initial tests, I get the different results depending on whether I'm using static or dynamic linking. But maybe it's me, I'll look more carefully later. How about pointing out the bug you found? Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pam is chatty when logging in via ssh
On Mon, Feb 03, 2003 at 01:54:45AM -0800, David P. Reese Jr. wrote: On current as of about four hours ago, sshd spits the following to the console after a successful login: Feb 3 01:41:29 metropolis sshd[550]: in _openpam_check_error_code(): pam_sm_setcred(): unexpected return value 24 It seems harmless, but pam doesnt sound happy. I did notice that mergemaster updated /etc/pam/sshd by adding some krb5 lines. That's odd. Assuming that pam_krb5 is the module which is returning `24', I fixed that 4 days ago (Wed Jan 29 21:20:38 2003 UTC). Are you certain you have rebuilt pam_krb5? What is the output of `ident /usr/lib/pam_krb5.so' (should show revision 1.13 or later). The `four hours' does indeed correspond to DES's enabling of pam_krb5 by default in etc/pam.d/sshd. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
OK, how about now? PFIL_HOOKS
Now that 5.0 has been released, can we please make PFIL_HOOKS the default? -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OK, how about now? PFIL_HOOKS
On Mon, Feb 03, 2003 at 07:37:06PM -0600, Jacques A. Vidrine wrote: Now that 5.0 has been released, can we please make PFIL_HOOKS the default? Oh, I should have said that I'm going to make the change in a few days if there are no objections. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Using 4.3-RELEASE's libc on 5.0 causes hard lockups
On Sun, Feb 02, 2003 at 11:41:32AM -0600, Kevin Day wrote: lrwxr-xr-x 1 root wheel 9 Feb 1 00:18 libc.so - libc.so.5 lrwxr-xr-x 1 root wheel 16 Jul 5 2002 libc.so.3 - /usr/lib/libc.so ^ This is seriously messed up. See below. -r--r--r-- 1 root wheel 571480 Aug 5 13:45 libc.so.4 -r--r--r-- 1 root wheel 836892 Feb 1 00:18 libc.so.5 Shouldn't libc.so.4 have been a symlink to libc.so after a compat4x install? In any case, doing that myself seemed to fix everything. No, this would cause you major problems. Binaries that expected the libc.so.4 interface would be calling into libc.so.5, and probably causing very strange behaviour. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Using 4.3-RELEASE's libc on 5.0 causes hard lockups
On Sun, Feb 02, 2003 at 11:53:22AM -0600, Kevin Day wrote: Ok, I admit, no matter how it happened, an application using the wrong libc is a bad thing. But, how are things supposed to work? Apps that need the old libc.so.4 will find it in /usr/lib/compat/libc.so.4 (or /usr/lib/libc.so.4 if you didn't remove it, for that matter). [...] In any case, a system lockup or being able to crash other user's processes just by having the wrong libc shouldn't be possible no matter what happens. Probably not, although if you have processes running as root and using the `wrong' libc, all bets are off. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dump -L and privilege
On Wed, Jan 29, 2003 at 06:17:31PM -0800, Kirk McKusick wrote: Alternative 1 `usermount' The first would be to change the default for vfs.usermount == 1 and then have dump -L create the snapshot in a directory owned by operator (or by whatever user runs the dumps). Then the snapshot could be created, used, and deleted by that user. Alternative 2 `/sbin/snapshot' The other alternative would be to create a setuid-to-root program that would take a snapshot and chown it to the user that does dumps. This setuid program could then be invoked by dump -L to create a snapshot for it. Despite a distaste for setuid executables, I think I'd prefer a simple /sbin/snapshot setuid program. Primarily, enabling `vfs.usermount' gives more privileges to more users than I'm comfortable with. Secondarily, /sbin/snapshot may be useful on its own. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: openpam error from sshd
On Mon, Jan 27, 2003 at 06:17:37PM +0100, Dag-Erling Smorgrav wrote: Kris Kennaway [EMAIL PROTECTED] writes: I've just updated bento to 5.0, and sshd is now giving the following error every few seconds: auth.err bento sshd[55737]: in _openpam_check_error_code(): pam_sm_setcred(): unexpected return value 24 Peter says he's seen this elsewhere on the cluster. What's going on? *grumble* it's a bug in one of our PAM modules (krb5, I think), which I never got around to fixing it because it isn't really important. Error 24 is PAM_NO_MODULE_DATA, which isn't an allowed return value for pam_setcred() according to the XSSO, but nobody really cares because anything else than PAM_SUCCESS is an error, so the bug doesn't have any adverse effect other than making OpenPAM bitch so I remember to fix it :) I believe I fixed this in revision 1.13 of pam_krb5.c. I'd be much obliged if you double-checked. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Sound familiar? 5.0-RC hangs on dual athlon
On Mon, Dec 09, 2002 at 10:47:24PM +0100, Julian H. Stacey wrote: I dropped back to a generic single CPU kernel. ( Which cancelled main reason I moved to 5.0-DP2: to get ATA bus working with dual, see my Nov. 22 Subject: 5.0-DP2: SMP+ATA OK. But 4.7 stable boot panic with ASUS P2L97-DS To: freebsd-current@ ) I'm down loading 5.0-RC1-i386-disc1.iso Well, I tried again, this time: = I built with DDB, INVARIANTS, INVARIANT_SUPPORT, WITNESS, and WITNESS_SKIPSPIN --- none of these were enabled previously. = I did not try to use ccd nor vinum --- I tried one and then the other previously. = I did not use UFS2 --- I formatted all large filesytems with UFS2 previously. So far things are peachy ... I've gotten along much futher than previously (restored all files from backup while building GNOME 2). Later (much later) I'll try to narrow the problem down further. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Sound familiar? 5.0-RC hangs on dual athlon
Hello All, I finally managed to put some time aside to redo my main development/desktop machine to run FreeBSD 5.0. (I've been running 5.x on my laptop for some months.) I had to retreat back to 4.7 because I could not get through some simple tasks without the system hanging. The system is a dual Athlon box with 1 GB RAM. The dmesg output is below. At first the system hung while I was building GNOME 2.0 and restoring some files from tape. It wasn't _completely_ hung: I could switch VTYs, and enter new commands (though it might take tens of seconds to echo my typing, and longer to actually execute, say, `ps'). I noticed that both an `ld' process and the `restore' process seemed to stuck in state `wdrain'. I attempted to reboot the system, but after several minutes it still had not appeared that it halted --- so I pulled the plug. I then tried again. This time, I thought perhaps that I would be gentler. I tried checking out the ports tree (over ssh) (I had done this previously successfully). Within two minutes, the system was `hung' again. The `cvs' process appeared to be stuck in `wdrain'. One more time. Again, I attempted to check out the ports tree. After 20 minutes or so, again the system was `hung', although this time I couldn't check whether there were any processes in `wdrain', because it was hung hard and completely. Does this ring bells for anyone? What should I look for when I get a few hours again to waste? Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-RC #1: Sat Dec 7 19:30:52 CST 2002 [EMAIL PROTECTED]:/spare1/obj/usr/src/sys/GENERIC Preloaded elf kernel /boot/kernel/kernel at 0xc06a4000. Preloaded elf module /boot/kernel/acpi.ko at 0xc06a40a8. Calibrating clock(s) ... TSC clock: 1194486067 Hz, i8254 clock: 1192995 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method Timecounter TSC frequency 1194678840 Hz CPU: AMD Athlon(tm) Processor (1194.68-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x661 Stepping = 1 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc044RSVD,AMIE,DSP,3DNow! Data TLB: 32 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 256 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 1073676288 (1023 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x006cb000 - 0x3ffe7fff, 1066520576 bytes (260381 pages) avail memory = 1036201984 (988 MB) bios32: Found BIOS32 Service Directory header at 0xc00f7440 bios32: Entry = 0xfd6a0 (c00fd6a0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd6a0+0x120 pnpbios: Found PnP BIOS data at 0xc00f7490 pnpbios: Entry = f:9ea2 Rev = 1.0 Other BIOS signatures found: Initializing GEOMetry subsystem random: entropy source mem: memory I/O Pentium Pro MTRR support enabled null: null device, zero device npx0: math processor on motherboard npx0: INT 16 interface acpi0: PTLTDRSDT on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 pci_open(1):mode 1 addr port (0x0cf8) is 0x80008004 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=700c1022) acpi0: power button is handled as a fixed feature programming model. acpi0: sleep button is handled as a fixed feature programming model. ACPI timer looks BAD min = 1, max = 4, width = 4 ACPI timer looks BAD min = 1, max = 4, width = 4 ACPI timer looks GOOD min = 1, max = 3, width = 3 ACPI timer looks GOOD min = 1, max = 3, width = 3 ACPI timer looks GOOD min = 1, max = 2, width = 2 ACPI timer looks GOOD min = 1, max = 3, width = 3 ACPI timer looks GOOD min = 1, max = 3, width = 3 ACPI timer looks BAD min = 1, max = 4, width = 4 ACPI timer looks GOOD min = 1, max = 3, width = 3 ACPI timer looks BAD min = 1, max = 4, width = 4 Timecounter ACPI-safe frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0x8008-0x800b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0x8080-0x80ff,0x8000-0x807f,0xcf8-0xcff iomem 0xdc000-0xd on acpi0 initial configuration \\_SB_.PCI0.ISA_.LNKA irq 10: [ 3 5 10 11] low,level,sharable 0.13.0 \\_SB_.PCI0.ISA_.LNKB irq
Re: lock order reversal and panic in kern_descrip.c
On Mon, Apr 22, 2002 at 11:28:41AM +0900, Jun Kuriyama wrote: Today's -current kernel. This happend when I invoke linux-netscape. Does it happen every time? I cannot reproduce it. What is odd is that fdcheckstd() is only called when exec'ing a set[ug]id executable -- any idea what set[ug]id program is being exec'd here? #14 0xc019d01b in fdcheckstd (td=0xe7f8ed50) at ../../../kern/kern_descrip.c:1532 #15 0xc01a04e2 in execve (td=0xe7f8ed50, uap=0xe805bcdc) at ../../../kern/kern_exec.c:372 My -CURRENT is a few days old. I'll see if updating allows me to reproduce the problem. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: lock order reversal and panic in kern_descrip.c
On Mon, Apr 22, 2002 at 10:35:49PM +0900, Jun Kuriyama wrote: A kern_descrip.c is updated by tanimura after your r1.137. Could you try with r1.138? Just updated to today's -CURRENT. I still cannot reproduce the issue. I'm curious ... could you send the output of pkg_info -L linux-netscape-navigator-4.79 | xargs ls -l ? Also, does `/compat/linux/bin/sh' blow up for you? Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: lock order reversal and panic in kern_descrip.c
On Tue, Apr 23, 2002 at 01:20:07AM +0900, Jun Kuriyama wrote: At Mon, 22 Apr 2002 11:09:26 -0500, Jacques A. Vidrine [EMAIL PROTECTED] wrote: I'm curious ... could you send the output of pkg_info -L linux-netscape-navigator-4.79 | xargs ls -l Attached. No setuid executables ... it's a mystery to me how one encounters this code path when running netscape :-( -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BIND 8.3.1 is *SLOW*
On Thu, Mar 28, 2002 at 12:51:12PM -0800, David O'Brien wrote: Ever since this commit: date: 2002-02-04 19:12:33; author: nectar; state: Exp; lines: +15 -1 Import of ISC BIND 8.3.1-REL. my DNS look ups are slow, like an order of magnitude slower. Any empirical observations? Hopefully others will see your message and can comment if they've noticed anything similar. I haven't. By chance was a FreeBSD'ism left out of the upgrade? I'll triple check. Also shouldn't host(1) obey /etc/nsswitch.conf? No: NAME host - look up host names using domain server -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gvim weird linkage
On Sat, Mar 09, 2002 at 03:36:20PM +0200, Vallo Kallaste wrote: Hi Gvim will link against nonexistent libraries, some of them seem to be derived from libXThrStub library name and some Xlib function names, very weird. I'm unable to build working gvim either from ports or by hand, also doesn't matter is it newest version or older 6.0 release. Update your -CURRENT. I noticed this problem a month or two ago, but with a recent build of -CURRENT, gvim finally works again. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX .Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make release failure in kerberos
On Thu, Feb 21, 2002 at 06:24:59AM +0200, John Hay wrote: Hi Jacques, Make release fails here. Can it be your changes to kerberos? Could be; I'll have a look. Thanks! -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: telnetd broken in -CURRENT
On Tue, Jan 29, 2002 at 06:38:57PM -0800, Terry Lambert wrote: Jacques A. Vidrine wrote: Meanwhile, do yourself a favor and use the Heimdal port if you want Heimdal Kerberos. I think he cares more about telnet than Heimdal. Do we install the Heimdal telnetd as the default telnetd in -CURRENT? I didn't think that we did. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: telnetd broken in -CURRENT
On Wed, Jan 30, 2002 at 01:47:24PM +, Mark Murray wrote: No. We dont. But if Kerberos5 is asked for, then BSD telnet is linked against Heimdal. I'm testing the fix, and will commit in a day or two. OK, great. I assume you'll import it on the vendor branch? -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: telnetd broken in -CURRENT
On Tue, Jan 29, 2002 at 01:09:33AM -0500, Alexander N. Kabaev wrote: I had this problem with telnet some time ago. See PR bin/32591 at http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/32591 for a patch which fixes the problem for me. The memory block is being freed twice in the Heimdal code. Unfortunately, PR got no attention whatsoever for over a month now. It is currently assigned to Mark Murray. Assar fixed this in Heimdal on 2001-06-24 (before Heimdal 0.4a). We badly need to update Heimdal in the base system. If assar or markm don't get to it soon (I assume they are swamped), I'll visit the issue in February. Meanwhile, do yourself a favor and use the Heimdal port if you want Heimdal Kerberos. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
PAM/Kerberos `integration'? (was Re: Step5, pam_opie OPIE auth fix for review)
On Mon, Jan 21, 2002 at 01:55:53PM -0800, Terry Lambert wrote: Jacques A. Vidrine wrote: In the way that the author of the PAM architecture from Sun spoke at the Silicon Valley BSD User's Group meeting, Do you have a reference, or do we have to guess what you are talking about? :-) I have my memory of the talk he gave, which included the idea that Sun was not supporting work to modify the PAM architecture to support Kerberos in the future. The PAM architecture doesn't need any modifications to support Kerberos. It supports Kerberos today. Basically, you can use it for authentication and password change, but for little else, and even those uses require going through incredible hoops (e.g. abusing the authentication module API to implement a credential cache). Did you need more? I guess so. There are many Kerberos 5 PAM modules in existence today, and they support interactive authentication pretty well. There is even some agreement among the authors of related modules on how the credentials cache can be exported for stacking (e.g. for DCE). I can't imagine what `incredible hoops' or `abuse' you might be talking about. The PAM API already includes entry points specificially for the management of credentials. Put another way, in your first sentence above, what might you mean by `for little else'? Are you really just fishing for Paul Fronberg's email address? No. I'm probably just wasting my time :-) You have stood up and asked for something, but have not given any indication of what it is you want to accomplish. Curiousity has the better of me. Maybe this release note from HP will explain the limitations satisfactorily: http://docs.hp.com/hpux/onlinedocs/J5849-90001/J5849-90001.html NB: This is just for authentication, mostly preauthentication. These seem to be limitations of HP's pam_krb5 module, not of PAM. And again, it is unclear what limitations you might be concerned about. No account management? Well, that's not Kerberos's job. No credentials management? That's a problem with HP's implementation -- see /usr/ports/security/pam_krb5 or pam_krb5 in our base system (they are closely related) for one way it can be done. Limited preauthentication choices? That has to do with the Kerberos implementation, not PAM. I feel like I'm having my leg pulled. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
On Sun, Jan 20, 2002 at 11:43:28PM -0800, Terry Lambert wrote: Once you guys have this all hammered out, are you going to integrate PAM and Kerberos? 8-) 8-) 8-). In what way do you mean? -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
On Mon, Jan 21, 2002 at 12:48:39PM -0800, Terry Lambert wrote: Jacques A. Vidrine wrote: On Sun, Jan 20, 2002 at 11:43:28PM -0800, Terry Lambert wrote: Once you guys have this all hammered out, are you going to integrate PAM and Kerberos? 8-) 8-) 8-). In what way do you mean? In the way that the author of the PAM architecture from Sun spoke at the Silicon Valley BSD User's Group meeting, Do you have a reference, or do we have to guess what you are talking about? :-) and there are just some things that can't be wedged into the PAM framework until the framework is changed. That is certainly true. It's also true if s/PAM/foo/ for most values of foo. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX .Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [OT] RMS Suing was [SUGGESTION] - JFS for FreeBSD
On Sat, Dec 15, 2001 at 04:43:37PM -0800, Matthew Dillon wrote: I am aware that certain long-standing RMS-specific projects, like emacs, require people who submit patches to sign-over their copyright, but I am not aware of people generally signing the copyright for their own GPL'd works over to the FSF. RMS wnats people to, but as far as I can tell most people have no desire to. All GNU projects appear to work this way. Contributions/patches are not accepted until you have completed paperwork with the FSF. I didn't realize how common this was myself until I started hacking on guile. I don't hack on it anymore. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX .Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: applix 5.0 and current
On Tue, Oct 16, 2001 at 12:43:13PM -0700, Brooks Davis wrote: I've been trying to get applix 5.0 to work and I've been running into some intresting problems. The first one was that current has the getresuid syscall and the gtk12 build detects and uses it. Unfortuatly FreeBSD 3.x and 4.x don't have this syscall so you can't use libgtk12 with old libc's if it's built on current. I was able to build a new one with use of getresuid disabled and that got the main program to load. It appears that the gtk12 port needs to disable this dubious feature or getresuid needs to be MFC'd all the way back to 3.x. A workaround that I used previously is to compile up getresuid.so and run Applix with e.g. `env LD_PRELOAD=/PATH/TO/getresuid.so applix'. -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.nectar.com/ Verio Web Hosting = FreeBSD UNIX =Heimdal Kerberos [EMAIL PROTECTED] = [EMAIL PROTECTED] = [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Undeletable files
On Wed, Aug 29, 2001 at 02:09:35AM -0500, David W. Chapman Jr. wrote: I cannot seem to delete some files that fsck can't seem to fix. Use clri(8) to stomp the directory that is giving you problems, then run fsck again. Repeat until the filesystem is clean. Then find your backup :-) Cheers, -- 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: WinModem Support/Learning the kernel Internals
On Tue, May 01, 2001 at 02:13:05AM +0300, Tomi Vainio - Sun Finland - wrote: Benjamin Close writes: Is anyone looking into converting the Linux winmodem driver ( Lucent Technologies binary object file compiled together with the linux kernel serial driver) into a freebsd device? Please check http://www.geocities.com/wtnbkysh/ . It should work under 4.2R. There is also some 5.0C patches but still some problems probably with interrupts. Apr 25 22:23:04 phb /boot/kernel/kernel: ltmdm0: Lucent Win Modem port 0x1c00-0x1cff,0x2f8-0x2ff mem 0xffefff00-0xffef irq 11 at device 2.0 on pci0 Apr 25 22:23:04 phb /boot/kernel/kernel: ltmdm0: using SHARED IRQ. Apr 25 22:23:04 phb /boot/kernel/kernel: ltmdm0: unable to activate interrupt in fast mode - using normal modeltmdm0: type Virtual 16550A Also I've used PPP with the following on a ThinkPad X20 running 4.3-RELEASE + wtnbkysh patches: ltmdm0: Xircom Win Modem port 0x1810-0x1817 mem 0xf4011000-0xf4011fff irq 9 at device 10.1 on pci 0 ltmdm0: using SHARED IRQ. ltmdm0: type Virtual 16550A This is on the EtherJet Mini-PCI card (combo: fxp + ltmdm). Cheers, -- 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: Building procedure of krb5 is broken
On Wed, Feb 21, 2001 at 10:06:29PM +0900, Jun Kuriyama wrote:
At 20 Feb 2001 09:44:01 GMT,
Makoto MATSUSHITA wrote:
It seems that add 'CFLAGS+=-I${KRB5OBJDIR}' to
src/kerberos5/lib/libgssapi/Makefile is required to fix this, since
krb5_err.h is not in ${KRB5DIR}/lib/krb5.
In my environment, buildworld was finished with attached patch. I
don't know KRB4 should be defined in this file or not. But in
crypto/heimdal/kdc/headers.h, krb.h (this file is not exist in heimdal
distribution) is included if KRB4 is defined.
So if MAKE_KERBEROS5=YES is set in /etc/make.conf, buildworld is
failed because krb.h is not found.
Last I looked (before assar's import), MAKE_KERBEROS5=yes required
that you also have MAKE_KERBEROS4=yes due to such dependencies.
Cheers,
--
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: /etc/shells #include syntax support patch
On Sun, Jan 28, 2001 at 10:13:49AM +0100, Steve O'Hara-Smith wrote: Hi, Asbestos suit on, round two. The patch below changes getusershell to support a #include syntax in /etc/shells. I guess this is what I object to. I don't particularly like having a new directive in a configuration file which lots of applications read directly. I would rather that a separate configuration file be read, for example, with a list of shells(5) format files to consult. In current, this could be an optional thing, activated in nsswitch.conf, e.g. make a ports source for shells, and activate it with: shells: files ports or whatever you would like to call the source. -- 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, 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, 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: VXA tape drive
On Mon, Jan 15, 2001 at 12:49:29PM -0600, David W. Chapman Jr. wrote: I checked in current with little luck. Does -current support VXA-1 tape drives by Ecrix. The site claims that freebsd does, but the only response by someone that has one says that it won't successfully backup. I've been using an external VXA-1 drive since October 1999 (FreeBSD 3.3 or so). It is currently attached to a FreeBSD 4.1 machine. I really love it. -- 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: Package installation location
On Sun, Dec 10, 2000 at 07:16:15PM +0100, Dag-Erling Smorgrav wrote: Forrest Aldrich [EMAIL PROTECTED] writes: Within the scope of this problem, would it not be simple to code in a configuration diretive in the build process, such that a simple entry in /etc/make.conf would tell the ports build where to install ($prefix)? You're about six years late. The ports system has used $PREFIX for precisely this purpose since October 1994. Actually see LOCALBASE, and perhaps X11BASE, which influence PREFIX. This is what you'd want to set in /etc/make.conf. -- 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
call for testers: nsswitch + dynamic linking
[Please follow-up to only one list] Hello, I need more testers for the following! nsswitch extends the C library so that arbitrary sources may be consulted by database routines such as getpwent, gethostbyname, and so on. This implementation was based on NetBSD's implementation. I have enhanced it to make the interfaces thread safe, and to provide support for dynamically loaded nsswitch modules. Patches for 4-STABLE and 5-CURRENT are at: http://www.nectar.com/freebsd/nsswitch. Also available there are patches for PADL.COM's nss_ldap so that it may be used with FreeBSD. Incidentally this also adds reentrant versions of common routines such as getpwnam_r. Note that routines that eventually call the resolver are only as thread safe as the resolver -- i.e. not really. Please contact me with any comments/bugs/patches. Cheers, -- 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: new rc.network6 and rc.firewall6
On Mon, Oct 23, 2000 at 02:25:40PM -0700, David O'Brien wrote: On Mon, Oct 23, 2000 at 05:07:42PM -0400, Brandon D. Valentine wrote: Hmm I don't have any NetBSD machines running the later 1.5 revisions yet, so I've not seen the new scripts, lynx ftp://ftp.netbsd.org/pub/NetBSD-current/src/etc/rc.d/ By the way, the author of this stuff (Luke Mewburn) says he'll post a summary of the design and implementation issues to this list in a few days. -- 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
Fwd: [cvs commit: src/lib/libc/net hesiod.c]
If you have machines running -CURRENT from September 9 - September 29, _and_ you created an /etc/nsswitch.conf with any of `passwd: dns', `group: dns', `passwd_compat: dns', `group_compat: dns', then you are vulnerable to a local attack. So upgrade :-) (or just apply the small patch) -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] - Forwarded message from Jacques Vidrine [EMAIL PROTECTED] - Date: Fri, 29 Sep 2000 05:56:34 -0700 (PDT) From: Jacques Vidrine [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: cvs commit: src/lib/libc/net hesiod.c nectar 2000/09/29 05:56:34 PDT Modified files: lib/libc/net hesiod.c Log: Ignore HESIOD_CONFIG and HES_DOMAIN environmental variables for set-user-ID and set-group-ID programs. Suggested by: Danny Braniss [EMAIL PROTECTED] Revision ChangesPath 1.2 +13 -3 src/lib/libc/net/hesiod.c - End forwarded message - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pw_class in _pw_passwd is null if __hashpw() is not called in prior
On Thu, Sep 28, 2000 at 10:50:53PM +0900, Seigo Tanimura wrote: Here is another possible trouble. While libc.so.4 with nsswitch no longer requires the magic '+' entry, libc.so.3 and earlier still require '+'. If one needs to support applications using libc.so.3, then one needs to use the nsswitch compat mode (which is the default). OTOH, I hope to have nsswitch in 4.2-RELEASE. (I do the develoment on 4-STABLE.) What we need before 5.0-RELEASE meets the world is a tool to find binaries linked against libc.so.3 and earlier, and give a warning. This would be useful in any case. It would also be helpful for us to (semi-)automatically update old binaries installed by ports. (I have been trying this for a couple of days) Personally I don't want sysinstall or make world to touch my ports. But a tool to do this would be great. -- 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: pw_class in _pw_passwd is null if __hashpw() is not called in prior
On Thu, Sep 28, 2000 at 10:24:01AM -0500, Dan Nelson wrote: Depends on what Seigo meant. If he meant that libc.so.4 and no /etc/nsswitch.conf implicitly adds a "+" to the end of /etc/passwd, that's definitely a bug. If you don't have an /etc/nsswitch.conf, then it behaves just like libc.so.3, i.e. only the files are consulted, unless you have a '+' entry. If he meant that libc.so.4 and an nsswitch.conf of "passwd: files nis" doesn't require a "+", that's fine. And that is how it works if you do have an nsswitch.conf like that. -- 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: pw_class in _pw_passwd is null if __hashpw() is not called in prior
On Fri, Sep 29, 2000 at 12:10:39AM +0700, Max Khon wrote: "passwd: compat" should require '+' if I understand it correctly You understand correctly :-) Further, this is the default when there is no /etc/nsswitch.conf. -- 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: pw_class in _pw_passwd is null if __hashpw() is not called in prior
On Sun, Sep 24, 2000 at 11:43:01PM +0900, Seigo Tanimura wrote:
As we are supposed to fill in all of the members in struct passwd
(like Solaris), _pw_passwd should have its initial value other than
zero.
static struct passwd _pw_passwd =
{
"",
"",
(uid_t)0, /* XXX Is zero appropriate? */
(gid_t)0,
(time_t)0,
"",
"",
"",
"",
(time_t)0,
0,
};
I agree -- it bit me while working on some additional nsswitch
backends. Using a pointer to an empty string would be more safe. As
to the XXX comment, those fields have been 0 forever, no point in
changing them now. Unless objections come up, I'll commit this change
or something similar with the next nsswitch commit.
Thanks for the suggestion!
--
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: /usr/local/etc/rc.d and /etc/rc.d
On Fri, Sep 08, 2000 at 04:47:15PM +0200, Neil Blakey-Milner wrote: Note the excessive use of "perl -i -pe 's/foo/bar/'" for in-place substitution. I've asked on at least two occasions for a simple, easy-to-use, thing to do it without doing a two-liner that copies to another file, and then replaces the old file with the new file. If it weren't for perl, we'd probably already have `sed -i' :-) -- 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
HEADS UP: nsswitch meets current
HEADS UP: nsswitch meets current Hello, I have just commited nsswitch support to FreeBSD-current. The code is based on NetBSD 1.4.2's nsswitch and I attempted to keep the implementations as close as possible. By creating an /etc/nsswitch.conf file, you can configure FreeBSD so that various databases such as passwd and group can be looked up using flat files, NIS, or Hesiod. To summarize, = Hesiod has been added to libc (see hesiod(3)). = A library routine for parsing nsswitch.conf and invoking callback functions as specified has been added to libc (see nsdispatch(3)). = The following C library functions have been modified to use nsdispatch: . getgrent, getgrnam, getgrgid . getpwent, getpwnam, getpwuid . getusershell . getaddrinfo . gethostbyname, gethostbyname2, gethostbyaddr . getnetbyname, getnetbyaddr . getipnodebyname, getipnodebyaddr, getnodebyname, getnodebyaddr As a side effect, by Hajimu UMEMOTO [EMAIL PROTECTED]'s suggestion (thanks!), the default for the resolver is now files, then dns. This is different than the traditional default of dns, then files. HOWEVER, note that since November 1998 we have installed a default host.conf that causes lookup to be files, then dns anyway. = host.conf has been removed from src/etc. rc.network has been modified to warn that host.conf is no longer used at boot time. In addition, if there is a host.conf but no nsswitch.conf, the latter is created at boot time from the former. See also hesiod.conf(5) and nsswitch.conf(5). Thanks to Luke Mewburn [EMAIL PROTECTED] for writing this freely distributable name-service switch implementation for the NetBSD Project. Thanks to those who sent in reports/suggestions/patches! Note that patches adding this support to 4.1-RELEASE and 4.1-STABLE are available at http://www.nectar.com/freebsd/nsswitch, as well as the patches that have been committed to -CURRENT. -- 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: nsswitch changes break world build
On Wed, Sep 06, 2000 at 03:21:00PM -0700, Matthew Jacob wrote: Are you sure you don't have a partial update? He's sure. I boo-boo'd :-) I merrily went out to eat after committing my changes, then checking out -CURRENT and watching it `make -j 4 buildworld' to completion. Of course I already had /usr/include/nsswitch.h, so it didn't blow up for me. Sorry! -- 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: People running with LOCALBASE set to something other than /usr/local?
On Wed, Aug 23, 2000 at 01:01:59AM -0500, Mike Meyer wrote: Um - why? If you removed the setting of LOCALBASE in that case, you wouldn't change the disk layout at all. I prefer installed executables, data files, and man pages to refer to /opt. Duh. However, I was wondering if there was anyone who could fix things that weren't PREFIX clean who would also find them on a regular basis. That's not you. Sorry to disappoint you. Patches are welcome. -- 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: People running with LOCALBASE set to something other than /usr/local?
On Wed, Aug 23, 2000 at 01:36:56PM +0100, Konstantin Chuguev wrote:
Just wondering: what is the reason of using /opt instead of /usr/local,
apart from Solaris influence?
No Solaris influence, actually. Just strlen("/opt") strlen("/usr/local").
It looks nicer to me. Secondarily to see if a ports behaves when
${LOCALBASE} != /usr/local.
Do you use /usr/local for anything?
Nope.
--
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: People running with LOCALBASE set to something other than /usr/local?
On Mon, Aug 21, 2000 at 11:59:26PM -0500, Mike Meyer wrote: I'm curious - are there any committers who regularly use a system with LOCALBASE set to something other than /usr/local? I have LOCALBASE=/opt for a couple of years now. OTOH, I also have a symlink from /usr/local - /opt due to a small but significant number of ports that are not PREFIX clean. -- 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: HEADS UP! New (incomplete) /dev/random device!
On Sun, Jun 25, 2000 at 12:55:47PM -0700, Kris Kennaway wrote: I don't know which applications depend on /dev/random providing entropy and which gather their own. SSH and SSL should not be used: PGP should be okay. FWIW, a quick look indicates: MIT Kerberos V gathers its own ``entropy'' when generating random keys Heimdal uses /dev/random This matters in particular for creating keys for servers. Session keys may or may not be a big deal, depending on the application. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP! New (incomplete) /dev/random device!
On Mon, Jun 26, 2000 at 04:09:26PM +0200, Leif Neland wrote: How much does this "unrandomness" matter? That's why I said `depending on the application'. It probably doesn't matter too much for a Kerberos session key that will be used for the duration of an ftp session. It definately matters if you just generated a keytab to use for your new server, and you use that key for the lifetime of your server (not atypical). How often are keys generated? If only once per program, then does it really matter if the keys are generated randomly or from my mothers maiden name? Consult Schroedinger's cat. Maybe it only `matters' if someone is looking for weak keys in your environment. :-) -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP! New (incomplete) /dev/random device!
On Sun, Jun 25, 2000 at 12:35:12PM +0200, Mark Murray wrote: 1) It is not yet cryptographically secure, so those of you using CURRENT for "live" projects, please be careful! I guess it follows that it is not a good idea to generate keys or certificates on -CURRENT for a while (until entropy comes back to town)? I don't know which applications depend on /dev/random providing entropy and which gather their own. If so, I think this needs an UPDATING entry, particularly since the symptoms could outlive the cause. i.e. something to the effect of ``Keys and certificates generated on -CURRENT on or after m/d/y should not be used'' and updated again when the entropy is again available. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -e option to umount?
[I think this thread belongs only on -current for the moment. Please followup there.] On Thu, Jun 22, 2000 at 01:44:47PM -0700, Brian Fundakowski Feldman wrote: For what it's worth, there's a port, ports/sysutils/eject, which is made to do this. I'm not one to deny a simple feature in the base system, though, even if this feature is not /really/ that simple. There are two problems with ports/sysutils/eject: = It uses only CDIOCEJECT, which will not work for all removable media (e.g. SCSI disks, tapes). = It tries to unmount the device after ejecting it. This doesn't make since for all devices. Even for those that it _does_ make sense, it can be hard to correctly determine how (by what name) the device is mounted. So I wrote a simple utility that ejects media as follows: = Check to see if the given device is known to cam, and if so use camlib to eject it. = If that doesn't work, try the CDIOCEJECT ioctl. = If that didn't work, give up. It is available as a port at: http://www.nectar.com/freebsd/neject.tar Included in the port distfile is a patch (umount.patch) that adds a `-e' option to umount. If you use it, then umount will run eject for each local filesystem that is unmounted. I figure umount should call eject, rather than the other way around, since umount already knows the device name and mount point. I actually think that there should be load/eject media ioctls defined that are not specific to CDs. I'll post a separate message to that effect on -current. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
comments wanted: media load/eject ioctls (was Re: -e option to umount?)
We've had a CDIOCEJECT ioctl `forever'. Several drivers support it, such as cd, acd, and wfd. However, there are other drivers that support removable media but do not support CDIOCEJECT: da and sa. Likewise we have CDIOCCLOSE which should cause a device to load its media. I want to add these ioctls to da and sa [1]. I don't like the CDIO name, though. I'd like to give these ioctls a different name. I'm not sure what header file might be appropriate for them. I'd like to keep the new ioctls binary-compatible with CDIOC(EJECT|CLOSE)-- i.e. use ioctls 24 28. Or maybe I'm the only one who wouldn't like to invoke the name CDIOCEJECT to unload a tape :-) Thanks, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] [1] Are there other drivers which should support media load/eject, that do not already? Do any systems have system-ejectable PC cards for example (never seen such myself)? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Gnome INSANE shared memory usage
On Fri, Jun 23, 2000 at 08:22:00PM +0300, Maxim Sobolev wrote: Hmm, where my crystal ball... Aha, I see - probably you are using Xfree 4.0, while your friend Xfree3.5*. It is where the problem lie (see below). Well, I use XFree86 4.0 with two displays, and GNOME 1.2, and I don't have the kind of usage that Christopher has. [just trying to halt a possible goose chase] -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Destabilization due to SMP development
On Tue, Jun 20, 2000 at 08:49:27PM +0200, Poul-Henning Kamp wrote: So: No I don't like -current being toast anymore than you do, but I don't think there is a viable alternative. Not even a seperate repository, as was done (briefly) for newbus? Of course, maybe that was done so briefly because it was painful... -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -e option to umount?
[trimmed cc: list, now including only -current] On Sun, Jun 18, 2000 at 11:54:51PM -0400, Francisco Reyes wrote: Also speaking from my own experience I would have expected something like this to be part of the system and would have never even looked for a port. And you'd find it, at least for SCSI devices, in camcontrol(8). e.g. % camcontrol eject cd0 This works for SCSI tapes as well. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
