Re: Should URL's be pervasive.
On Thu, Aug 30, 2001 at 11:10:18AM -0400, Leo Bicknell wrote: I ran into a pair of all too common annoyances this morning that got me thinking. Via the magic of cut and paste I ended up with the following two sorts of command lines: mutt mailto:[EMAIL PROTECTED] traceroute http://www.ufp.org/ These of course come from the 'copy link location' available in most browsers. When pasted into most Unix commands (with the exception of fetch and lynx, of course) the result is something that just doesn't work. This got me thinking, should all commands know how to take an URL, and 'do the right thing'? Could this be made easy by providing a standard URL parsing library that all commands could use for parsing? Ick. If I wanted this kind of integration I would run Windows, KDE, or GNOME instead of my nice, stable, predictable, lightweight desktop environment. In my opinion, the URLification of the user environment would be a negative unless there were a very easy way to turn it completely off. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville [EMAIL PROTECTED] GPG key fingerprint = 332D 97F0 6321 F00F 8EE7 2D44 00D8 F384 75BB 89AE To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: The future of multiprocessors (was: SMP in 2.4 (fwd))
On Thu, Apr 19, 2001 at 12:10:51PM +0930, Greg Lehey wrote: More to the point, the processors of the not-too-distant future will have multiple processors on the single die. Multiprocessors are here to stay. That day will be here in Q4 2001. IBM is planning to launch a new system based on the Power4 processor. According to the design papers I've read, the Power4 has two processor cores per die. Big computing it certainly not going away. SMP may not be the most efficient design, but NUMA appears to have a lot of promise. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville [EMAIL PROTECTED] GPG key fingerprint = 332D 97F0 6321 F00F 8EE7 2D44 00D8 F384 75BB 89AE To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Request for review (HW checksum patches)
On Sat, Mar 25, 2000 at 10:36:24PM -0600, Jonathan Lemon wrote: On Sat, Mar 25, 2000 at 09:25:33PM -0500, Keith Stevenson wrote: Which card(s) do your patches support? I have a 3Com 3CR990-TX (typhoon) which does both TCP checksumming and 3DES (for IPSec). I'd love to give it a try. Right now, just the Alteon cards. Support for the 3Com-XL can probably be added without too much trouble. I don't see a driver for the 3Com-990 though, and I can't find a reference to it on the 3Com website, is this a new card? I'm not sure whether or not it is generally available yet. I got it as part of an early release preview program. Needless to say, the only drivers that come prepackaged with it are for Win2k. I'll see if I can find anything which resembles documentation in the stuff which came with the card. (I highly doubt that I will.) Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville [EMAIL PROTECTED] PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Request for review (HW checksum patches)
On Sat, Mar 25, 2000 at 06:56:42PM -0600, Jonathan Lemon wrote: The patches I have were designed to solve a single problem, just checksum offloading. There are enough bits left in the new flag field that you could use for something else, I don't know enough about what you'd want to do to say if it's enough for a general mechanism. Which card(s) do your patches support? I have a 3Com 3CR990-TX (typhoon) which does both TCP checksumming and 3DES (for IPSec). I'd love to give it a try. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville [EMAIL PROTECTED] PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: softupdates and debug.max_softdeps
On Fri, Dec 31, 1999 at 08:49:01AM +0800, Peter Wemm wrote: FYI: On hub.freebsd.org (the freebsd mailing list server), if we activate softupdates on the disk containing the postfix spool, the machine reboots (silently if I recall correctly) within 5 minutes of postfix starting up. This is a much smaller system of course, with smaller memory and filesystem working set. (postfix spool of ~50-80MB, 256MB ram). I thought I'd post this as a real-use datapoint. I'm using a postfix/FreeBSD 3.3-STABLE system as the central mail hub for the University of Louisville. I have softupdates enabled on the mail spool, I process about 75K messages per day, and I have absolutely no stability problems. The system is a PentiumPro 200 MHz with 128 MB RAM. Kernel was compiled on Sep 27 14:32:45 EDT 1999. This system in only a relay/router system. It handles no local deliveries. Just another real-use data point. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville [EMAIL PROTECTED] PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: softupdates and debug.max_softdeps
On Fri, Dec 31, 1999 at 09:19:37AM -0800, Matthew Dillon wrote: It seems that all the reported problems so far are on -stable systems. I wonder if the same problem occurs under -current? Also, all the reported problems so far are under 3.3 (for example, hub is running 3.3-RC in a Sep 12 build). How about 3.4? I am running 3.3 and everything is fine. I'm using IDE drives on my system, so I was wondering if they might be putting enough of a brake on the I/O subsystem to avoid the problem Peter is reporting. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville [EMAIL PROTECTED] PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cache-friendly scheduling for SMP
On Thu, Sep 16, 1999 at 12:25:52PM +, greg wrote: I'm trying to run 1-2 processes with very large memory footprints on my P2 SMP machine. I'm finding that the process switches cpu's quite often, which obviously isn't good for the caches on the CPU. Can anybody point me to a paper, mailing list discussion, etc. that discusses scheduling processes to not thrash the cpu caches? Or if there's anything in place, how I can take advantage of it, etc. I got stumped on the idea a while ago, so I'm really curious... Disclaimer All I've heard is a marketing presentation. I haven't seen this is the real world yet. /Disclaimer IBM just released a new version of AIX (4.3.3). One of the big features is CPU affinity in order to made better use of the CPU caches. They claim to have done this be having a separate run queue for each CPU. Just food for thought, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville k.steven...@louisville.edu PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: CFD: bogomips CPU performance metric
On Thu, Sep 02, 1999 at 10:40:30AM -0700, Nick Sayer wrote: Description of BogoMIPS deleted Would anyone scream and projectile-vomit if I added this to identcpu.c? I might. :-) Why exactly, except to keep up with the Linux kidz, do we need this? I recognize that this is solely a cosmetic change, but one of the things I hold over the heads of the Linux folks I deal with is the fact that FreeBSD is a professional quality operating system which doesn't need useless blinking lights like BogoMIPS. Chalk me up as one of the people who considers "Linux works like that" as a negative. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville [EMAIL PROTECTED] PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CFD: bogomips CPU performance metric
On Thu, Sep 02, 1999 at 10:40:30AM -0700, Nick Sayer wrote: Description of BogoMIPS deleted Would anyone scream and projectile-vomit if I added this to identcpu.c? I might. :-) Why exactly, except to keep up with the Linux kidz, do we need this? I recognize that this is solely a cosmetic change, but one of the things I hold over the heads of the Linux folks I deal with is the fact that FreeBSD is a professional quality operating system which doesn't need useless blinking lights like BogoMIPS. Chalk me up as one of the people who considers Linux works like that as a negative. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville k.steven...@louisville.edu PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Proposal: Add generic username for 3rd-party MTA's
On Wed, Sep 01, 1999 at 03:16:48PM -0700, Doug wrote: It's not a stupid question at all. There is already such a utility in the majordomo port, perhaps make this its own port and add that as a dependency? We've already been told that postfix (one of the favorite replacement MTA's for our crowd) uses a different name and group, so this proposed change won't help it at all. Postfix doesn't care what the userid/uid and group name/gid are. Calling the user "postfix" just appears to be a common convention, therefore the proposed smtp user would address postfix's needs. Qmail, as has already been pointed out, is a very different story. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville [EMAIL PROTECTED] PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposal: Add generic username for 3rd-party MTA's
On Wed, Sep 01, 1999 at 06:33:06PM +0200, Sheldon Hearn wrote: Hi folks, I plan to add a user ``smtp'' with UID 25 and a member of group ``mail'', for use in running non-priveledged MTA's in FreeBSD. This is primarily for the convenience of maintainers of mail ports. This sounds quite reasonable to me. We already have a precedent in the bind (uid=53) user. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville k.steven...@louisville.edu PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Proposal: Add generic username for 3rd-party MTA's
On Wed, Sep 01, 1999 at 03:16:48PM -0700, Doug wrote: It's not a stupid question at all. There is already such a utility in the majordomo port, perhaps make this its own port and add that as a dependency? We've already been told that postfix (one of the favorite replacement MTA's for our crowd) uses a different name and group, so this proposed change won't help it at all. Postfix doesn't care what the userid/uid and group name/gid are. Calling the user postfix just appears to be a common convention, therefore the proposed smtp user would address postfix's needs. Qmail, as has already been pointed out, is a very different story. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville k.steven...@louisville.edu PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Was someone looking for a BSD licensed stat(1)?
I've put a new version of stat(1) up for review. I've incorporated a few of the features that were requested. I honestly haven't figured out how to implement the display of selected fields yet. I realize that this isn't a huge step forward over the previous revision, but my hacking hours are limited. Code is available at: http://www.kagekaze.org/stat.tar.gz Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville k.steven...@louisville.edu PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Was someone looking for a BSD licensed stat(1)?
I hacked this together last night. The only GNU code I looked at was the
Linux stat(1u) man page. (A man page is forthcoming, especially if there is
some interest in using this implementation.) The code is also available at
http://www.kagekaze.org/stat.c
Regards,
--Keith Stevenson--
--
Keith Stevenson
System Programmer - Data Center Services - University of Louisville
[EMAIL PROTECTED]
PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0
/* stat.c: Human readable interface to stat(2) system call */
/*-
* Copyright (c) 1999 Keith Stevenson
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* $Id: stat.c,v 1.2 1999/07/28 19:33:10 ktstev01 Exp $
*/
#ifndef lint
static const char copyright[] =
"Copyright (c) 1999\nKeith Stevenson. All rights reserved.\n";
static const char rcsid[] =
"$Id: stat.c,v 1.2 1999/07/28 19:33:10 ktstev01 Exp $";
#endif /* not lint */
#include sys/types.h
#include sys/stat.h
#include errno.h
#include grp.h
#include pwd.h
#include stdio.h
#include string.h
#include sysexits.h
#include time.h
/* stat: Display the contents of an inode in a human friendly format. */
int
main(int argc, char *argv[])
{
charftype[20];
charfmode[11];
int count;
struct group*gp;
struct passwd *pw;
struct stat inode;
struct tm *atime, *mtime, *ctime;
for (count = 1; count argc; count++) {
if (lstat(argv[count], inode) != -1) {
/* Initialize */
memset(fmode, '-', sizeof(fmode));
fmode[10] = '\0';
/* Interpret file type */
switch (inode.st_mode S_IFMT) {
case S_IFIFO:
strncpy(ftype, "FIFO", sizeof(ftype));
fmode[0] = 'p';
break;
case S_IFCHR:
strncpy(ftype, "Character Special",
sizeof(ftype));
fmode[0] = 'c';
break;
case S_IFDIR:
strncpy(ftype, "Directory", sizeof(ftype));
fmode[0] = 'd';
break;
case S_IFBLK:
strncpy(ftype, "Block Special", sizeof(ftype));
fmode[0] = 'b';
break;
case S_IFREG:
strncpy(ftype, "Regular", sizeof(ftype));
break;
case S_IFLNK:
strncpy(ftype, "Symbolic Link", sizeof(ftype));
fmode[0] = 'l';
break;
case S_IFSOCK:
strncpy(ftype, "Socket", sizeof(ftype));
fmode[0] = 's';
break;
case S_IFWHT:
strncpy(ftype, "Whiteout", sizeof(ftype));
fmode[0] = '?';
break;
default:
strncpy(ftype, "Unknown", sizeof(ftype));
fmode[0] = '?';
break;
}
/* Inte
Re: Was someone looking for a BSD licensed stat(1)?
On Wed, Jul 28, 1999 at 04:01:10PM -0400, Brian F. Feldman wrote: Since you've got it in RCS, you shouldn't have any problem adding new features. How about a selectable display of fields, and ability to put them in machine-readable (read: no cut required) form? I'd suggest having a function that would printf "%s: whatever", arg1 for humans and "whatever" for machines, selectable by something like a -c "compact output flag." Here's the GPLd stat I have: Sure, I can work on that. It would be helpful if you could include a few sample outputs that I could work from. The current version already solves my problems, but I'll be happy to hack away at it if you are interested in including it in FreeBSD in some way. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville [EMAIL PROTECTED] PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Was someone looking for a BSD licensed stat(1)?
I hacked this together last night. The only GNU code I looked at was the
Linux stat(1u) man page. (A man page is forthcoming, especially if there is
some interest in using this implementation.) The code is also available at
http://www.kagekaze.org/stat.c
Regards,
--Keith Stevenson--
--
Keith Stevenson
System Programmer - Data Center Services - University of Louisville
k.steven...@louisville.edu
PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0
/* stat.c: Human readable interface to stat(2) system call */
/*-
* Copyright (c) 1999 Keith Stevenson
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* $Id: stat.c,v 1.2 1999/07/28 19:33:10 ktstev01 Exp $
*/
#ifndef lint
static const char copyright[] =
Copyright (c) 1999\nKeith Stevenson. All rights reserved.\n;
static const char rcsid[] =
$Id: stat.c,v 1.2 1999/07/28 19:33:10 ktstev01 Exp $;
#endif /* not lint */
#include sys/types.h
#include sys/stat.h
#include errno.h
#include grp.h
#include pwd.h
#include stdio.h
#include string.h
#include sysexits.h
#include time.h
/* stat: Display the contents of an inode in a human friendly format. */
int
main(int argc, char *argv[])
{
charftype[20];
charfmode[11];
int count;
struct group*gp;
struct passwd *pw;
struct stat inode;
struct tm *atime, *mtime, *ctime;
for (count = 1; count argc; count++) {
if (lstat(argv[count], inode) != -1) {
/* Initialize */
memset(fmode, '-', sizeof(fmode));
fmode[10] = '\0';
/* Interpret file type */
switch (inode.st_mode S_IFMT) {
case S_IFIFO:
strncpy(ftype, FIFO, sizeof(ftype));
fmode[0] = 'p';
break;
case S_IFCHR:
strncpy(ftype, Character Special,
sizeof(ftype));
fmode[0] = 'c';
break;
case S_IFDIR:
strncpy(ftype, Directory, sizeof(ftype));
fmode[0] = 'd';
break;
case S_IFBLK:
strncpy(ftype, Block Special, sizeof(ftype));
fmode[0] = 'b';
break;
case S_IFREG:
strncpy(ftype, Regular, sizeof(ftype));
break;
case S_IFLNK:
strncpy(ftype, Symbolic Link, sizeof(ftype));
fmode[0] = 'l';
break;
case S_IFSOCK:
strncpy(ftype, Socket, sizeof(ftype));
fmode[0] = 's';
break;
case S_IFWHT:
strncpy(ftype, Whiteout, sizeof(ftype));
fmode[0] = '?';
break;
default:
strncpy(ftype, Unknown, sizeof(ftype));
fmode[0] = '?';
break;
}
/* Interpret file mode */
if (inode.st_mode S_IRUSR)
fmode[1] = 'r
Re: Was someone looking for a BSD licensed stat(1)?
On Wed, Jul 28, 1999 at 04:01:10PM -0400, Brian F. Feldman wrote: Since you've got it in RCS, you shouldn't have any problem adding new features. How about a selectable display of fields, and ability to put them in machine-readable (read: no cut required) form? I'd suggest having a function that would printf %s: whatever, arg1 for humans and whatever for machines, selectable by something like a -c compact output flag. Here's the GPLd stat I have: Sure, I can work on that. It would be helpful if you could include a few sample outputs that I could work from. The current version already solves my problems, but I'll be happy to hack away at it if you are interested in including it in FreeBSD in some way. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville k.steven...@louisville.edu PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PAM LDAP in FreeBSD
On Wed, Jul 21, 1999 at 10:57:24AM -0600, Oscar Bonilla wrote: Lots snipped I don't see where the modularized crypt would fit in then... i totally agree that pam has this capability i was just trying to fit in the crypt stuff people have been working on. (Mark Murray: jump in here if I get this wrong) The way I understand it, a PAM module (pam_unix?) would need to be able to look at the password hash and figure out which of the crypt functions to call. Ideally, the PAM configuration would be able to specify which crypt functions are valid for the system. That said, one of the very attractive features of specifying the crypt function in the login class is the ability to assign different crypt algorithms on a user by user basis. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville [EMAIL PROTECTED] PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM LDAP in FreeBSD
On Wed, Jul 21, 1999 at 10:57:24AM -0600, Oscar Bonilla wrote: Lots snipped I don't see where the modularized crypt would fit in then... i totally agree that pam has this capability i was just trying to fit in the crypt stuff people have been working on. (Mark Murray: jump in here if I get this wrong) The way I understand it, a PAM module (pam_unix?) would need to be able to look at the password hash and figure out which of the crypt functions to call. Ideally, the PAM configuration would be able to specify which crypt functions are valid for the system. That said, one of the very attractive features of specifying the crypt function in the login class is the ability to assign different crypt algorithms on a user by user basis. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville k.steven...@louisville.edu PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PAM LDAP in FreeBSD
On Mon, Jul 19, 1999 at 06:22:17PM +0200, Dag-Erling Smorgrav wrote: Oscar Bonilla [EMAIL PROTECTED] writes: On Mon, Jul 19, 1999 at 06:13:51PM +0200, Dag-Erling Smorgrav wrote: Oscar Bonilla [EMAIL PROTECTED] writes: the idea is to have an entry in the /etc/passwd enabling LDAP lookups. the Entry would be of the form ldap:*:389:389:o=My Organization, c=BR:uid:ldap.myorg.com Horrible idea. suggestions? /etc/auth.conf Given that this is a PAM module, wouldn't /etc/pam.conf be more appropriate? Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville [EMAIL PROTECTED] PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM LDAP in FreeBSD
On Mon, Jul 19, 1999 at 06:22:17PM +0200, Dag-Erling Smorgrav wrote: Oscar Bonilla oboni...@fisicc-ufm.edu writes: On Mon, Jul 19, 1999 at 06:13:51PM +0200, Dag-Erling Smorgrav wrote: Oscar Bonilla oboni...@fisicc-ufm.edu writes: the idea is to have an entry in the /etc/passwd enabling LDAP lookups. the Entry would be of the form ldap:*:389:389:o=My Organization, c=BR:uid:ldap.myorg.com Horrible idea. suggestions? /etc/auth.conf Given that this is a PAM module, wouldn't /etc/pam.conf be more appropriate? Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville k.steven...@louisville.edu PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Setting up a firewall with dynamic IPs
On Tue, Jul 13, 1999 at 10:16:32PM +0930, Kris Kennaway wrote: On Tue, 13 Jul 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote: I was checking out the firewall setup in /etc/rc.firewall, and noticed that the simple example relied on a fixed IP address for the external interface. I don't know ahead of time what IP address is going to be allocated to me before I dial up. Would it be possible to specify an interface (tun0) rather than an IP address? You could probably do it from /etc/ppp/ppp.linkup, which knows your IP address as MYADDR. But if you just have asingle machine on the end of the dialup then I find I can get away with just specifying the netmask from which the dialup IPs are assigned in place of a single address - all that can happen is that packets get through your firewall destined to a nonexistent address (i.e. if you allow incoming port Y traffic then people can send to port Y on nonexistent IP addresses (i.e. your peer addresses) which will be dropped by the kernel). Keep in mind that if securelevel 2, the ipfw rules can not be changed. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville [EMAIL PROTECTED] PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Setting up a firewall with dynamic IPs
On Tue, Jul 13, 1999 at 10:16:32PM +0930, Kris Kennaway wrote: On Tue, 13 Jul 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote: I was checking out the firewall setup in /etc/rc.firewall, and noticed that the simple example relied on a fixed IP address for the external interface. I don't know ahead of time what IP address is going to be allocated to me before I dial up. Would it be possible to specify an interface (tun0) rather than an IP address? You could probably do it from /etc/ppp/ppp.linkup, which knows your IP address as MYADDR. But if you just have asingle machine on the end of the dialup then I find I can get away with just specifying the netmask from which the dialup IPs are assigned in place of a single address - all that can happen is that packets get through your firewall destined to a nonexistent address (i.e. if you allow incoming port Y traffic then people can send to port Y on nonexistent IP addresses (i.e. your peer addresses) which will be dropped by the kernel). Keep in mind that if securelevel 2, the ipfw rules can not be changed. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville k.steven...@louisville.edu PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: docs/12377: doc patch for login_cap.
On Tue, Jul 06, 1999 at 06:54:20PM +0400, Alexander Voropay wrote: AFAIK, most of login_cap functions could be done via PAM subsystem. It's sound very strange to have two different subsystem with too close functions... Based upon several conversations at USENIX, PAM integration is still a work in progress. John Polstra laid out a lot of the groundwork, but there is still a lot of work left to be done. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville [EMAIL PROTECTED] PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: docs/12377: doc patch for login_cap.
On Tue, Jul 06, 1999 at 06:54:20PM +0400, Alexander Voropay wrote: AFAIK, most of login_cap functions could be done via PAM subsystem. It's sound very strange to have two different subsystem with too close functions... Based upon several conversations at USENIX, PAM integration is still a work in progress. John Polstra laid out a lot of the groundwork, but there is still a lot of work left to be done. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville k.steven...@louisville.edu PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ufs/ffs resize?
On Sun, Jun 27, 1999 at 12:35:54AM +0200, Ollivier Robert wrote: Another datapoint ot consider, it seems that Linux (at least the derivative version maintained by Alan Cox -- the other one :) ) has now grown an LVM system (probably à la HP or AIX). That's what I've been told yesterday during a small conference about Linux and free software in France (and where I did a talk about FreeBSD *grin*). Hmmm. It might be from SGI. SGI has donated XFS to Linux and is actively marketing it on their Intel based systems. http://www.news.com/News/Item/0,4,36807,00.html?st.ne.fd.tohhed.ni Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville [EMAIL PROTECTED] PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Inetd and wrapping.
On Sat, Jun 26, 1999 at 06:55:53AM +0200, Sheldon Hearn wrote: I don't think the core team would care enough about something this silly to bother making a decision, so I'm just watching what people have to say. I'm leaning toward leaving the nowrap feature out. FWIW, I think that leaving out the nowrap feature would be a very good idea. I'm willing to agree (somewhat grudgingly) that incorporating libwrap is a definite feature improvement, but this conf file change doesn't seem to buy much at all. If a user needs that level of granularity, they can disable libwrap support on the inetd command line and use tcpd. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville k.steven...@louisville.edu PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ufs/ffs resize?
On Sun, Jun 27, 1999 at 12:35:54AM +0200, Ollivier Robert wrote: Another datapoint ot consider, it seems that Linux (at least the derivative version maintained by Alan Cox -- the other one :) ) has now grown an LVM system (probably à la HP or AIX). That's what I've been told yesterday during a small conference about Linux and free software in France (and where I did a talk about FreeBSD *grin*). Hmmm. It might be from SGI. SGI has donated XFS to Linux and is actively marketing it on their Intel based systems. http://www.news.com/News/Item/0,4,36807,00.html?st.ne.fd.tohhed.ni Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville k.steven...@louisville.edu PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
On Fri, Jun 25, 1999 at 02:50:34PM +0200, Sheldon Hearn wrote: On Fri, 25 Jun 1999 05:44:06 MST, Aaron Smith wrote: could you please restate the argument for this? i still haven't heard a decent reason for this sort of conf format perturbation. I'm so tempted to say me too. :-) John Baldwin has suggested that he had functionality with inetd + tcpd that he doesn't have any more with inetd + libwrap. As much as I appreciate the work that has gone into adding this feature to inetd, I'm starting to wonder if it is causing more harm than good. One of the things I good-naturedly complain about to my Linux-using friends is the large number of seemingly gratuitous changes which make Linux different that other similar operating systems. As well-intentioned as adding libwrap support to inetd was, I'm having trouble finding a justification for the change. What is possible now that wasn't possible with tcpd from the ports collection? Why incorporate libwrap (and make our inetd functionally different from everyone else's) instead of bringing tcpd into the base system? I realize that I'm more than a bit late in raising these issues. I didn't even realize that libwrap had been added to inetd until Mark Murray told me at USENIX. (Somehow I missed all of the announcements.) Assuming that it is too late to undo the changes to inetd, I'd like to urge that we not also start tinkering with the format of inetd.conf. I'm just not comfortable with creating FreeBSD-isms when there isn't a clear improvement in functionality. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville k.steven...@louisville.edu PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
On Fri, Jun 25, 1999 at 04:05:05PM +0200, Sheldon Hearn wrote: On Fri, 25 Jun 1999 09:31:26 -0400, Keith Stevenson wrote: What is possible now that wasn't possible with tcpd from the ports collection? Why incorporate libwrap (and make our inetd functionally different from everyone else's) instead of bringing tcpd into the base system? If we _don't_ use tcpd, we save an exec on every call to every wrapped service. Ok, I can see that as a win, especially for very busy servers. (I'm thinking ISPs here.) I know we're all worried about creeping featurisms, but think about what we'll end up with here. We'll end up with an inetd that does _not_ wrap by default (discussed with jkh in private mail). So people wanting to carry on using tcpd stubbornly will be more than welcome to do so. We'll also end up with an inetd that _can_ wrap if it's told to (-w and -ww). So we end up offering a better super-server than we had before, with no backward compatibility problems, and no additional incompatibilities with other systems (I can't find an inetd that uses the -w flag for anything). Good. I was worried that we would have to add a flag to turn wrapping off. This makes the change much more palatable. The additional option in inetd.conf is not something I want. However, it's something someone has made a legitimate public argument for, to which I can't come up with a decent rebuttal. As long as this new option can safely be omitted by those of us who prefer a more traditional approach, I can't argue about it too much either. The purist in me doesn't like it, but I can't come up with a rebuttal either. Ciaol, Sheldon (who is quickly learning that you can't please 'em all at all) Only a fool\h\h\h\h optimist tries to... :) Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville k.steven...@louisville.edu PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
