Re: HEADS UP: sendmail updated from 8.9.3 to 8.11.0 in -current
At 01:49 PM 8/13/00 +0200, Johan Granlund wrote: I think we have to support rfc2554 autenthication (With MECH LOGIN for Outlook) out of the box if we are serius about mailserver and security. If you're serious about security, you shouldn't support LOGIN (or PLAIN) unless adequate privacy protections are in place. If you're serious about standards, you won't support LOGIN. Given that OpenSSL is in the base system, there is little reason not to support BOTH StartTLS and SASL "out of the box". I would suggest the authentication defaults be relative secure, as in "noplain,noanonymous". This will force use of StartTLS to allow use of PLAIN/LOGIN mechanisms. A make.conf knob to use a userinstalled library may create problems with different versions of Cysus-SASL. I had some problems with that when uppgrading my mailservers to Sendmail 8.10. I'd recommend bringing Cyrus-SASL into the base system eventually under the same rational used to bring OpenSSL in. Kurt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
Note that there should be no need to cron the job. You only need to save one set of bits to be used as a seed for the next startup. And one set of bits SHOULD be as good as any other. I suggest you (at boot time): 1: open seed file for read unlink seed file use seed file + available entropy to seed algorithm close the seed file 2: open for seed file for write write X bytes for next time close file Note that even if you do cron step 2, I recommend highly you mix in whatever entropy you can gather at boot time into the initial seeding. This will ensure any reuse of the seed file (such as if you crash between steps 1 and 2) will result in different bit sequences. Regards, Kurt At 10:14 PM 7/17/00 +0200, Sheldon Hearn wrote: On Mon, 17 Jul 2000 19:33:40 +0200, Mark Murray wrote: That is an idea I can use! :-) See the recently fixed and documented crontab(5) @reboot, in fact. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
PAM'ized su(1)
I've noticed that su(1) is not yet PAM'ized. Is anybody working on this? If so, I'm willing to test. If not and time permits, I'll see if I can whip up an appropriate patch. Kurt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PAM'ized su(1)
At 02:32 PM 1/8/00 -0500, Garrett wrote: On Sat, 08 Jan 2000 11:29:36 -0800, "Kurt D. Zeilenga" [EMAIL PROTECTED] said: I've noticed that su(1) is not yet PAM'ized. Is anybody working on this? If so, I'm willing to test. If not and time permits, I'll see if I can whip up an appropriate patch. If you do this, please take care not to break WHEELSU (and its Kerberos equivalent), which has its fingers everywhere. I would suggest: If NO_PAM, the behavior would be simple, traditional BSD behavior with very few optional features (such as WHEELSU). If PAM, then Kerberos and Skey support would be provided via appropriate PAM modules. This means that auth.conf can go away. WHEELSU can (and should) be provided by pam_wheel. So, the very first thing I would do to PAM'ize su.c would be to: mv su.c su.c.orig unifdef -UKERBEROS -USKEY su.c.orig su.c Then I would add in PAM calls behind #ifndef NO_PAM. Kurt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PAM'ized su(1)
At 04:43 PM 1/8/00 -0500, Garrett Wollman wrote: Hmmm. I don't see any such module. Or are you proposing to write one? No. I'd just pull the pam_wheel from the Attic. Kurt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PAM'ized su(1)
At 11:08 PM 1/8/00 +, David Malone wrote: On Sat, Jan 08, 2000 at 02:14:10PM -0800, Kurt D. Zeilenga wrote: At 04:43 PM 1/8/00 -0500, Garrett Wollman wrote: Hmmm. I don't see any such module. Or are you proposing to write one? No. I'd just pull the pam_wheel from the Attic. If it came from the linux version of pam, then pam_wheel is broken. Did you try the "use_uid" option? Kurt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: LDAPed FreeBSD
At 02:29 PM 7/4/99 -0700, Amancio Hasty wrote: Record locking and batch requests is a bit more difficult to solve perhaps someone in the list can shed light into this problem for instance does LDAPv3 provide such mechanism? LDAP (v2 or v3) does not provide record locking, client/server transactions, nor any specific batching requests. The "L" in LDAP means lightweight. I think LDAP-based directory service could be used to manage a wide variety of system information including configuration information for various other network services. However, using LDAP directory services to manage network-services state information is likely not appropriate application of LDAP. For example, while it may make sense to use an LDAP directory service to manage the configuration and master zone information for a Domain Name Service, it would not be wise to use an LDAP directory service to maintain state information (such records created due to DHCP operations) of Domain Name Service. If there any bugs in the ldap server I will probably fix them or better yet the people working on openldap will fix them. OpenLDAP, like FreeBSD, is user maintained and developed. All users are encouraged to contribute to the project. We can surely use your help! Kurt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
At 07:56 PM 6/4/99 +0200, Poul-Henning Kamp wrote: I still think the right thing is: default to keepalives. set the timeout to a week. OpenLDAP slapd, like may other daemons, relies on timeouts being a reasonably short (a few hours) to deal with dead streams. Dead streams occur for a wide variety of reasons and erver applications need an effective mechanisms to deal with them. Changing the timeout to a week would render the SO_KEEPALIVE mechanism ineffective. Personally, I advocate using sysctl (in rc files) to set the default to on and leaving the kernel alone. Kurt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
compiler specs for -pthread/-kthread
To facilate auto detection of the local threading environment, it would be nice if the -?thread options set all the necessary compiler/linker flags. It is a common practace for such options to specify both compilation and link options. I suggest the EGCS specs be adjusted to: -pthread = -D_THREAD_SAFE -D_UTHREADS -lc_r -kthread = -D_THREAD_SAFE -D_KTHREADS -lpthread If the LinuxThread port is targetted to be -kthread: -kthread = -D_REENRANT -D_LINUXTHREADS -lpthread If the LinuxThread port is NOT targetted to be -kthread, I suggest another -?thread option be added and the library specified as -llthread. -?thread = -D_REENTRANT -D_LINUXTHREADS -llthread After modify the specification, the headers/libraries would be adjusted as needed. I can easily submit diffs if desirable. Kurt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
GNU regex (Was: egcs knob and objective C)
At 03:32 PM 4/2/99 -0600, Jacques Vidrine wrote: On 2 April 1999 at 22:25, Doug Rabson d...@nlsystems.com wrote: We should also consider installing libbfd. If and when we bring in a newer version of gdb, it would be a good idea to avoid importing yet another version of libiberty and libbfd. ... and GNU regex. If you mean a version of regex included in the LGPL'ed libc, yes, then this point might be mute. However, if you mean the regex/rx distributions, please, no. GNU regex and GNU rx distributions are both under the GPL. Henry Spencer's regex has a promiscious license. Even if a LGPL'ed distribution was available, I wouldn't recommend switching without a significant and demonstrated technical advantage. I've found that each implementation is even with the others. I would suggest GNU regex be made ports unless some base application required the -lgnuregex. Kurt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
3.0-current(12/98) - RELENG_3 problems
I had a hoard of problems upgrading a 3.0-current a.out system circa ~12/7/98 to RELENG_3. After CVSuping, running make aout-to-elf-build would complain about OBJFORMAT previously being set in /etc/make.conf (which I don't think it was) and suggested I override it. Setting OBJFORMAT to elf, the aout-to-elf would fail unable to find make. Setting OBJFORMAT to aout, cause a nasty warning about a.out not being supported. I tried a few combinations and could not get aout-to-elf to build. However, I was around this by: setenv OBJFORMAT aout setenv REALLY_WANT_DEPRECIATED_AOUT 1 make buildworld mergemaster make installworld reboot make upgrade Kurt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: -current (aka 4.x) breaks libtool
At 05:47 PM 1/23/99 +0100, Alexander Sanda wrote:
Even most recent versions of libtool (1.2e imho) fail to check for
freebsd4* (as expected). As a result, they set can_build_shared to no
which disables building of shared libraries.
Here is a simple patch (which I'll forward this to the libtool
maintainers).
I've just applied the following to the OpenLDAP copy of ltconfig.
It should work for FreeBSD 4.0 and beyond...
Index: ltconfig
===
RCS file: /repo/OpenLDAP/pkg/ldap/build/ltconfig,v
retrieving revision 1.4
diff -u -r1.4 ltconfig
--- ltconfig1998/12/21 22:08:06 1.4
+++ ltconfig1999/01/23 19:38:42
@@ -776,8 +776,13 @@
hardcode_shlibpath_var=no
;;
- # FreeBSD 3, at last, uses gcc -shared to do shared libraries.
- freebsd3*)
+ freebsd1*)
+ld_shlibs=no
+can_build_shared=no
+;;
+
+ # FreeBSD 3 and greater uses gcc -shared to do shared libraries.
+ freebsd* )
archive_cmds='$CC -shared -o $lib$libobjs'
hardcode_libdir_flag_spec='-R$libdir'
hardcode_direct=yes
@@ -1129,8 +1134,12 @@
finish_cmds='PATH=$PATH:/sbin ldconfig -m $libdir'
shlibpath_var=LD_LIBRARY_PATH
;;
+
+freebsd1*)
+ dynamic_linker=no
+ ;;
-freebsd3*)
+freebsd*)
version_type=freebsd
library_names_spec='${libname}${release}.so.$versuffix $libname.so'
if [ -x `/usr/bin/objformat` ]; then
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: -D_REENTRANT (Was: Using LinuxThreads)
Richard Seaman, Jr. wrote: On Thu, Jan 21, 1999 at 02:00:53PM -0800, Kurt D. Zeilenga wrote: For kernel threading you just use libc. Whether or not libc generates thread safe (re-entrant) calls depends on whether its also linked with a library that 1) sets __isthreaded to a non-zero value, 2) has a _spinlock() implementationm, and 3) implements the functions flockfile, funlockfile, etc. There are also a few macros in header files that require _THREAD_SAFE to be defined to be thread safe. I was hoping to be able to produce one ldap library that could be safely linked with or without threads. However, if I must define _THREAD_SAFE to generate code to be linked with threads then I must produce two libraries (-lfoolib compiled with -U_THREAD_SAFE and -lfoolib_r with -D_THREAD_SAFE). _THREAD_SAFE is only used in stdio.h. Looking at what's there, it could be rewritten to eliminate _THREAD_SAFE entirely, at a (very slight) performance penalty. You'd have to check __isthreaded (could be done once, instead of twice, as in the code now) each time you call one of the functions defined within the _THREAD_SAFE switch. All _THREAD_SAFE does is let you avoid checking __isthreaded when you're not threaded. So, if I want to produce a library which can be safely used by both threaded and non-threaded applications I should NOT define -D_THREAD_SAFE such that __isthreaded is always checked by the library. In effect, -D_THREAD_SAFE makes the generated code non-thread UNSAFE. - Kurt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: -D_REENTRANT (Was: Using LinuxThreads)
Richard Seaman, Jr. wrote: On Fri, Jan 22, 1999 at 09:49:23AM -0800, Kurt D. Zeilenga wrote: Richard Seaman, Jr. wrote: _THREAD_SAFE is only used in stdio.h. Looking at what's there, it could be rewritten to eliminate _THREAD_SAFE entirely, at a (very slight) performance penalty. You'd have to check __isthreaded (could be done once, instead of twice, as in the code now) each time you call one of the functions defined within the _THREAD_SAFE switch. All _THREAD_SAFE does is let you avoid checking __isthreaded when you're not threaded. So, if I want to produce a library which can be safely used by both threaded and non-threaded applications I should NOT define -D_THREAD_SAFE such that __isthreaded is always checked by the library. I guess I was a little unclear. 1) I think you would have to rewrite a little bit of the header to use the __isthreaded test on a couple of more functions. 2) If you always define -D_THREAD_SAFE, __isthreaded will be checked whether you're threaded or not. I would think that most third party libraries (from Ports) do not compile with -D_THREAD_SAFE. As such, __isthreaded won't be checked and the library cannot be safely used in a threaded environment. You could also just eliminate _THREAD_SAFE entirely by letting __isthreaded get checked on each relevant call. I would much prefer this. Then third party libraries compiled without -D_THREAD_SAFE can be used in threaded environments (though they might require external synchronization). Kurt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Using LinuxThreads
At 06:12 PM 1/21/99 +0200, Jeremy Lea wrote: On Tue, Jan 19, 1999 at 09:11:51AM -0600, Richard Seaman, Jr. wrote: Actually, the new version, in FreeBSD ports form, doesn't require -DLINUXTHREADS anymore, but it does require -I/usr/local/include to pick up the right header, since it installs a pthread.h into /usr/local/include. This conflicts with the pthread.h in /usr/include. It doesn't conflict, it overrides the pthread.h in /usr/include iff the port is installed AND the application is compiled with -I/usr/local/include. Sounds a lot like how various other 'replacement' libraries are implemented. This is nagging at me. Having two headers of the same name, but importantly different content is asking for touble. There needs to be a way to ensure that only one or the other is picked up. The best way I can think of is to only include the contents of the user thread pthread.h if _THREAD_SAFE is defined (to force people to use the right defines...) and the contents of kernel thread pthread.h if _REENTRANT (and not _THREAD_SAFE) is defined. This has the added bonus of meaning that most linux apps wont have to be patched. Of course, this would only work if the contents of the two pthread.h files were merged. I'm not sure this is a good idea. If you did this, do NOT use -D_REENTRANT or -D_THREAD_SAFE as the conditional to determine the content. Use -DLINUXTHREADS or something. To many applications have configure scripts which might find /usr/local/lib/libpthread, but not /usr/local/include/pthread.h, or find /usr/lib/libc_r and find /usr/local/include/pthread.h. Garbage in, garbage out. If the configure script in handed ill defined environment settings (CPPFLAGS, LDFLAGS) you get what you deserve! Thinking Can gcc be made to define _THREAD_SAFE automatically if -pthread is given? And _REENTRANT if -kthread is given? -pthread/-kthread, in my option, should be considerred linker options (basically just a short hand for -lc_r -nostdlib) BTW, why does FreeBSD use -D_THREAD_SAFE AND -D_REENTRANT (math.h) while most other PThread (final) implementations use -D_REENTRANT? Also, the cc(1) says to use -D_THREADSAFE not -D_THREAD_SAFE. Personallly, I think -DREENTRANT should be used for include all prototypes for reentrant functions not requiring thread support (like strtok_r) and -D_THREAD_SAFE routines only implemented in -lc_r. If possible, functions should be implemented in both -lc and -lc_r such that 3rd party libraries wouldn't have to create both a -lfoolib vs. -lfoolib_r versions (unless their _r versions requires threading). Kurt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
-D_REENTRANT (Was: Using LinuxThreads)
Richard Seaman, Jr. wrote: BTW, why does FreeBSD use -D_THREAD_SAFE AND -D_REENTRANT (math.h) while most other PThread (final) implementations use -D_REENTRANT? Don't know. Using _REENTRANT would be preferable, IMO. Now if only a committer would agree... (I'll send patches if needed). Also, the cc(1) says to use -D_THREADSAFE not -D_THREAD_SAFE. Hmm. Not on my machine. :) http://www.freebsd.org/cgi/man.cgi?query=ccapropos=0sektion=0manpath=FreeBSD+3.0-currentformat=html Personallly, I think -DREENTRANT should be used for include all prototypes for reentrant functions not requiring thread support (like strtok_r) and -D_THREAD_SAFE routines only implemented in -lc_r. I think _THREAD_SAFE should be used as a switch when compiling libc/libc_r to turn on libc_r specific options, which is how it is primarily used now. Then it shouldn't be used in the headers if at all possible! _REENTRANT should be used in all libc/libc_r and system headers to turn on generic thread safe options. -D_REENTRANT should turn on reentrant functions, some of which may or may not be thread safe, that do not require threading support to implement. Reentrant functions that require threading support to implement should only be behind a different define. I think the problem is that folks tend to think the reentrant functions are only for use in threaded applications. They are quite useful in non-threaded applications as well (especially strtok_r). If possible, functions should be implemented in both -lc and -lc_r such that 3rd party libraries wouldn't have to create both a -lfoolib vs. -lfoolib_r versions (unless their _r versions requires threading). For kernel threading you just use libc. Whether or not libc generates thread safe (re-entrant) calls depends on whether its also linked with a library that 1) sets __isthreaded to a non-zero value, 2) has a _spinlock() implementationm, and 3) implements the functions flockfile, funlockfile, etc. There are also a few macros in header files that require _THREAD_SAFE to be defined to be thread safe. I was hoping to be able to produce one ldap library that could be safely linked with or without threads. However, if I must define _THREAD_SAFE to generate code to be linked with threads then I must produce two libraries (-lfoolib compiled with -U_THREAD_SAFE and -lfoolib_r with -D_THREAD_SAFE). This is quite painful. Many 3rd packages won't go through the pain. They will generate one library and assume all users will compile/link with compatible flags. Of course, most users don't know how their libraries were built nor pay much attention when configure dependent software. We run into this big time with OpenLDAP and third party packages such as DB2. It gets real complicated with try to link with multiple third party libs which may or may not be compiled with -D_THREAD_SAFE. errno was the biggest problem, but its conditional declaration of it has long since been removed. 3rd party library implementors need to be careful when using any function with a conditional declaration as you don't know which you'll get when an application is linked. We also only use reentrant functions where exist in -lc and avoid functions such as feof that may have conditional declarations. This allows us to build one -lldap that *can be* safely used by both threaded and non-threaded applications. libc_r could be modified so that is doesn't replace libc, but rather is an addon, comparable to the kernel threaded libc case. But, it would involve a bit of work. -- Richard Seamman, Jr. email: d...@tar.com 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
