Re: USFS (User Space File System)
: :Portal FS did give me a couple of starting points.. It looks interesting. :Just for my own clarification... how would this be different than NFS :(specifically local NFS)? : :-- :David Cross | email: [EMAIL PROTECTED] :Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd NFS isn't a fun protocol to implement. I'd implement a user-level filesystem interface protocol like this: * Have a device similar to portal that a user process can open for the server interface. * Have the ability to mount the 'client side' of the device once the 'server side' has been opened by the user process. * VOP Requests through the mount point are routed to the user process and responses returned. * Device driver handles auto termination of any pending commands if the user process close()'s the server side interface. * User process uses read() and write() to read request structures and write back response structures. (Thus the user process can use select() if it wishes). The request structure can contain a data pointer length. If the device is passing a read or write request to the user level server, it mmap's the data block into the server's address space prior to queueing the command and unmaps it after receiving the response. It would be really cool if someone were to write something like this. I don't think it would be terribly difficult except for the mmap() piece. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: softupdates on root partition, no floppy
On Saturday, 17th July 1999, Matthew Dillon wrote: :Is there any way to force softupdate on on a mounted system, or do I have to :either move the / to another machine, or move a floppydrive to this machine? If you boot single-user, root will be mounted read-only and you should be able to 'tunefs -n enable /dev/rda0a' and reboot. I gave up using soft updates on root because of the delayed delete behaviour. I kept filling up root while updating kernels. It doesn't gain you much on little used file systems anyway. So, I recommend people leave root alone. Stephen. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
At 11:40 AM 18/07/99 -0700, you wrote: Tim Baird wrote: I hope everyone is benefitting by these simple facts *chuckle* "Simple facts.." You sound like my physics professor. I for one am benefitting very much from the discussion. I got hired at my current job as a software person, but I have a background in hardware so I try and make it into the NOC every excuse I get (promotability, don't you know). It always helps if sound like I have a vague idea what I'm talking about. :) I'll take that as a compliment ;) I just made up my first ethernet cables the other day, and learned an interesting tidbit that I'm sure is beyond elementary to most of you, but may benefit someone else. What I was told is that the reason Cat 5 cable is so much more efficient is that each of the 4 pairs of wire is twisted at a different rate. This helps reduce the possibility of frequency synchronization for the EM fields the pairs create. Your description (what you were told) here is incorrectthe number of twists in a cable had **NO** effect on the spectral content of the cunducted signal or resulting radiated/induced signal.to do so would require the conductors to have a nonlinear conduction characteristic which they most assuredly do not (for all practical purposes). The design of the cable is such that adjacent pairs have as little effectively parallel length as possible. Obviously, the currents in the wires share the same axis, so the magnetic coupling is only reduced by the fact that interfering magnetic fields will tend to induce a common mode current in adjacent pairs...particulary since both conductors in the receiving cable pair --on average-- are exposed equally, the idea in "randomizing" the twists is to reduce the capacitive coupling as much as possible. Capacitive coupling is a more localized effect, and thrives when conductors share a common plane in close proximity...this is why capacitors are designed as two metal plates very close together..the electric field between the plates (conductors) is much higher than if they were perpendicular...or not nicely parallel. I hope this clarifies the situation :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
On Mon, 19 Jul 1999, Per Lundberg wrote: I need a libc 100% compatible with glibc to make porting (from Linux) easier. And, as a side note, I think both FreeBSD and Linux would benefit of having compatible libc:s. I seriously doubt this will make porting any easier. 99% of the porting issues you'll run into, are from a.) lack of sys/types.h being included, or order of headers being included. b.) dependencies on Linux-specific ioctls or syscalls, such as clone, which are not really libc related. c.) dependencies on bugs in glibc. Perhaps porting BSD libc to Linux would be easier? I doubt it. The glibc has been designed with portability in mind (hell, it's purported to run on Irix), FreeBSD's with security and speed. - alex What I am is what I am, What you are is what you are - Edie Brickell (ain't she profound?) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On Sun, 18 Jul 1999 [EMAIL PROTECTED] wrote: Please read the documentation. This is hard since the actual machines and switches are almost 6000 miles away from me and the last time I checked, it didn't come with manuals. I know my way around the Cisco routers but the switches is still a mystery... All of the Cisco documentation is available on WWW. Use it! I known it is but I was talking about the printed copy... Start at http://www.cisco.com/, follow the "Technical documents" and then the "Documentation home page" link. The manual for your switch is available, that's where I found the "show mac-address-table" command. Atleast the Cisco documentation is good... The Ascend documentation sucks big time since none of the stuff in the manual matches the actual OS on the system. Cheers, Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
On Mon, 19 Jul 1999, Alex Zepeda wrote: I seriously doubt this will make porting any easier. You think so? I experience a lot of this when I try to recompile stuff for FreeBSD (most of it are due to lack of a real getopt routine). c.) dependencies on bugs in glibc. What bugs have you found in glibc 2.1.1? Have you reported those to the GNU folks? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
On Mon, 19 Jul 1999, Per Lundberg wrote: You think so? Yes. I experience a lot of this when I try to recompile stuff for FreeBSD (most of it are due to lack of a real getopt routine). *sigh* It's quite easily argued that depending on a *NON STANDARD* getopt routine is a bug. AFAIK *ONLY* glibc has the long-getopt crap, and if that's the only thing you're running into, it should be easy enough to rip out the long getopt code, and add a few proper defines and have the standard libc coexist peacefully with the GNU getopt. c.) dependencies on bugs in glibc. What bugs have you found in glibc 2.1.1? Have you reported those to the GNU folks? I personally haven't found any, but I've seen for instance, kcalc is riddled with ifdefs and warnings about floating point precision stuff and RH 5.something due to glibc bug(s). - alex I thought felt your touch In my car, on my clutch But I guess it's just someone who felt a lot like I remember you. - Translator To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On Sun, 18 Jul 1999, Jonathan M. Bresler wrote: I guess I forgot about the overhead. I've tested between two FreeBSD machines using Intel Pro100+ NIC cards connected to a Cisco 2924XL Switch Full Duplex and never seen anything close to the speeds. using netperfv2pl3 and FreeBSD 2.2.8 on 300MHz PII with fxp cards (all from memory), i routinely get TCP_STREAM to pushd 94Mbps. i use these machines for stressing every else we have at work. Hmmm, has anyone tried a full duplex test before? Since it seems like the bottleneck is really the speed of the disks.. Cheers, Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
How much memory do we need to install?
AFAIK, the minimum memory for installation is still 5 MB, and the problems people had with 8MB machines failing to install was a bug, right? What's the current status? Greg - Forwarded message from Thierry Herbelot [EMAIL PROTECTED] - Delivered-To: [EMAIL PROTECTED] Date: Mon, 19 Jul 1999 09:49:01 +0200 Reply-To: [EMAIL PROTECTED] Organization: ALCATEL CIT Nanterre X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en To: Ben Salem [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] X-Loop: FreeBSD.ORG Precedence: bulk You must have more than 8 Megs to install FreeBSD TfH Ben Salem wrote: Im attempting to install FreeBSD 3.2-RELEASE on a 486 8mb ram. Everything goes ok until the installation actually begins, it gets to chunk 1 of 106 then stops. The install seems to work fine on my other machines. I have replaced the NIC card, so I think I can rule that out. Any ideas? Thanks Ben Salem - End forwarded message - -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On Mon, 19 Jul 1999, Reinier Bezuidenhout wrote: Hi ... We have previously done many network performance tests for our products running on FreeBSD ... We have found that when ever there is disk accessing involved, it is not a good idea to look at the transfer figures. We did tests with ftp and is was slow (compared to only memory generated data e.g. ttcp) yeah, I guess all tests should be done without requiring the use of the disk. 1. If you want to test the network speed ... use ttcp or something that generates the data and doesn't read it from disk. ttcp works. The only problem is when I tried it in both directions, at once. the total becomes 11.xMbytes/sec total as opposed to 9.4Mbytes/sec when doing it in one direction only. 2. When doing full-duplex and using fxp cards, stay away from X-over cables ... use a full-duplex switch etc. ... the fxp cards are not made to work with X-over cables (as far as I know - ala Intel spec) note ... only for full-duplex tests. Does anyone actually use X-over cables for 100Mbps Full Duplex since 3Com said CrossOver cables are not rated for 100Mbps or something even though it's Cat5. Actually, in the older Intel docs for the Pro100B, it does say to connect using X-over cable to the switch. We have done tests in full-duplex with non Intel cards (because we did not have a switch at that time :)) and with max size packets we got around 188.00 Mbps using the de0 driver. Pretty interesting. How did you do the full duplex tests? Cheers, Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] On Sun, 18 Jul 1999, Jonathan M. Bresler wrote: I guess I forgot about the overhead. I've tested between two FreeBSD machines using Intel Pro100+ NIC cards connected to a Cisco 2924XL Switch Full Duplex and never seen anything close to the speeds. using netperfv2pl3 and FreeBSD 2.2.8 on 300MHz PII with fxp cards (all from memory), i routinely get TCP_STREAM to pushd 94Mbps. i use these machines for stressing every else we have at work. Hmmm, has anyone tried a full duplex test before? Since it seems like the bottleneck is really the speed of the disks.. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Buildworld failing from 3.1 to 3-2.stable...
I have a box running 3.1-stable that I wanted to update. sups fine, but the build dies in login with: === usr.bin/login cc -O -pipe -static -Wall -DLOGIN_ACCESS -DLOGALL -I/usr/obj/n/FreeBSD/RELENG_3/src/tmp/usr/include -c /n/FreeBSD/RELENG_3 /src/usr.bin/login/login.c /n/FreeBSD/RELENG_3/src/usr.bin/login/login.c: In function `main': /n/FreeBSD/RELENG_3/src/usr.bin/login/login.c:129: warning: argument `argv' might be clobbered by `longjmp' or `vfork' cc -O -pipe -static -Wall -DLOGIN_ACCESS -DLOGALL -I/usr/obj/n/FreeBSD/RELENG_3/src/tmp/usr/include -c /n/FreeBSD/RELENG_3 /src/usr.bin/login/login_access.c cc -O -pipe -static -Wall -DLOGIN_ACCESS -DLOGALL -I/usr/obj/n/FreeBSD/RELENG_3/src/tmp/usr/include -c /n/FreeBSD/RELENG_3 /src/usr.bin/login/login_fbtab.c cc -O -pipe -static -Wall -DLOGIN_ACCESS -DLOGALL -I/usr/obj/n/FreeBSD/RELENG_3/src/tmp/usr/include -o login login.o logi n_access.o login_fbtab.o -lutil -lcrypt -lpam /usr/obj/n/FreeBSD/RELENG_3/src/tmp/usr/lib/libpam.a(pam_static_modules.o): In function `_pam_get_static_sym': pam_static_modules.o(.text+0x179): undefined reference to `skeyaccess' pam_static_modules.o(.text+0x275): undefined reference to `rad_create_request' pam_static_modules.o(.text+0x283): undefined reference to `rad_strerror' pam_static_modules.o(.text+0x29d): undefined reference to `rad_put_string' pam_static_modules.o(.text+0x2b2): undefined reference to `rad_put_string' pam_static_modules.o(.text+0x2dc): undefined reference to `rad_put_string' pam_static_modules.o(.text+0x2ea): undefined reference to `rad_strerror' pam_static_modules.o(.text+0x308): undefined reference to `rad_put_attr' pam_static_modules.o(.text+0x316): undefined reference to `rad_strerror' pam_static_modules.o(.text+0x32a): undefined reference to `rad_put_int' pam_static_modules.o(.text+0x33e): undefined reference to `rad_strerror' stdin What am I missing here? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
2nd draft: README.serial for handbook
The second draft of the serial console section in the FreeBSD handbook is ready. It is available at the same URL as below. Please review and correct any technical, grammatical, or whatever errors. Thank you. Kazu From time to time people ask questions about the serial console. As README.serial is buried deep inside the kernel source tree, it's almost time to have a decent text on the serial console in our handbook. I am reformatting README.serial so that it can be included in our handbook, and adding bits and pieces to clarify things. I haven't finished it yet, but would like to have your comments now, so that we can make it more informative and useful. I put up the HTML version in: http://www.freebsd.org/~yokota/serialconsole.html and the SGML version in: http://www.freebsd.org/~yokota/serial-console.sgml Please have a look and send me comments, corrections, additional useful text, relevant pointers, etc. Some notes: - The text describes FreeBSD versions 3.0 and 3.1 or later. Version 3.0 doesn't have our new boot loader, so there is a note in the introduction section about it. - Because there are many differences regarding the serial console setup between 2.X systems and 3.X systems, I don't directly deal with 2.X systems in this text. - I am not a SGML expart ;- formatting and links may be wrong. - Some sections are not yet finished :-) - The chapter number is arbitrary. When this text will be eventually included in the handbook, I expect Nik will put it somewhere suitable and give appropriate chapter number. Thank you. Kazu PS: I don't subscribe to the doc ML. Please send mail to the hackers ML or to me directly. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
Hi .. 1. If you want to test the network speed ... use ttcp or something that generates the data and doesn't read it from disk. ttcp works. The only problem is when I tried it in both directions, at once. the total becomes 11.xMbytes/sec total as opposed to 9.4Mbytes/sec when doing it in one direction only. If the devices are set at full-duplex then you are looking at something else ... the standard size for ttcp packets is 8k ... maybe the switch etc. that you are connected to doesn't handle fragmented packets very well. But ... what it rather seems like .. is that the devices are not in full-duplex mode generating a lot of collisions. After a test with transfers in both directions .. check the number of collisions with "netstat -in". If the number of collisions is not high .. - wait a moment ... are you using ttcp with tcp or udp option ... if you are using tcp (the default) then when transfering data you have acks going in both directions which could cause collisions on a full-duplex line ... try the same with the -u option for UDP. Check our setup below ... I'll explain some things there. Also check with "netstat -sn" to see if there are any other counters that increase with the full-duplex transfers. 2. When doing full-duplex and using fxp cards, stay away from X-over cables ... use a full-duplex switch etc. ... the fxp cards are not made to work with X-over cables (as far as I know - ala Intel spec) note ... only for full-duplex tests. Does anyone actually use X-over cables for 100Mbps Full Duplex since 3Com said CrossOver cables are not rated for 100Mbps or something even though it's Cat5. Actually, in the older Intel docs for the Pro100B, it does say to connect using X-over cable to the switch. Yes ... to a switch maybe ... but not fxp to fxp ... when transfering small packets .. you get a lot of "device timeouts". We have done tests in full-duplex with non Intel cards (because we did not have a switch at that time :)) and with max size packets we got around 188.00 Mbps using the de0 driver. Pretty interesting. How did you do the full duplex tests? I'll describe the setup briefly ... :) We had 3 machines two PII-400 as the generators and a PII-400 as the machine in the middle ... So we have a setup that looks like this ... - -- - | Gen 1 |-| Router |-| Gen 2 | - -- - Now .. here is a trick ... add entries manually in the Router's tables to simulate machines on each side that "does not exist". The reason for this is that we don't want the machines on the side to be generating AND excepting packets ... we just want them to generate packets at max network rate and nothing else. We then start a ttcp on both sides to the "non existing" machines. This means the router will be forwaring packets it receives without any machines having to be there because of the entries in the routing table. (we did this because we did not have another two fast machines at that time, but we did check the packets to make sure everything goes through and are not dropped etc. - it was some time ago :) ) We start ttcp with the following command ttcp -t -s -u -p 7000 -n nice large number -l 1472 10.0.0.1 the size of 1472 generates nice 1514 size UDP packets :) We then let the test run ... and check the throughput ... We used CAT5 X-over cables ... Hopw this helps Reinier To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: How much memory do we need to install?
3.2-RELEASE installs just fine on an 8 meg 386. -STABLE runs just fine. -Original Message- From: Greg Lehey [mailto:[EMAIL PROTECTED]] Sent: Monday, July 19, 1999 2:04 AM To: Brian McGroarty; FreeBSD Hackers; FreeBSD Committers Subject: How much memory do we need to install? AFAIK, the minimum memory for installation is still 5 MB, and the problems people had with 8MB machines failing to install was a bug, right? What's the current status? Greg - Forwarded message from Thierry Herbelot [EMAIL PROTECTED] - Delivered-To: [EMAIL PROTECTED] Date: Mon, 19 Jul 1999 09:49:01 +0200 Reply-To: [EMAIL PROTECTED] Organization: ALCATEL CIT Nanterre X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en To: Ben Salem [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] X-Loop: FreeBSD.ORG Precedence: bulk You must have more than 8 Megs to install FreeBSD TfH Ben Salem wrote: Im attempting to install FreeBSD 3.2-RELEASE on a 486 8mb ram. Everything goes ok until the installation actually begins, it gets to chunk 1 of 106 then stops. The install seems to work fine on my other machines. I have replaced the NIC card, so I think I can rule that out. Any ideas? Thanks Ben Salem - End forwarded message - -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
On Mon, 19 Jul 1999, Alex Zepeda wrote: It's quite easily argued that depending on a *NON STANDARD* getopt routine is a bug. I know it isn't standard. But it works well, and is used by a lot of programs. Perhaps it should have been put in another library than libc, though. Actually, I'd better suggest this to the GNU people right ahead. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
On Mon, Jul 19, 1999, Per Lundberg wrote: On Mon, 19 Jul 1999, Alex Zepeda wrote: It's quite easily argued that depending on a *NON STANDARD* getopt routine is a bug. I know it isn't standard. But it works well, and is used by a lot of programs. Perhaps it should have been put in another library than libc, though. Actually, I'd better suggest this to the GNU people right ahead. What is the point of using GNU-getopt over the standard getopt other than --foo-bar flags that everyone I know hates? -- |Chris Costello [EMAIL PROTECTED] |Watch out for off-by-one errors. `-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
On Mon, 19 Jul 1999, Per Lundberg wrote: # On Mon, 19 Jul 1999, Alex Zepeda wrote: # # It's quite easily argued that depending on a *NON STANDARD* getopt routine # is a bug. # # I know it isn't standard. But it works well, and is used by a lot of # programs. Perhaps it should have been put in another library than libc, # though. Actually, I'd better suggest this to the GNU people right ahead. How about gnugetopt? FreeBSD already has a port, devel/libgnugetopt, that does this. :) -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
On Mon, 19 Jul 1999, Chris Costello wrote: What is the point of using GNU-getopt over the standard getopt other than --foo-bar flags that everyone I know hates? Nothing. But I don't think they're as bad as you say, especially when you're new to a program and don't know the short options yet. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
On Mon, 19 Jul 1999, Steve Price wrote: How about gnugetopt? FreeBSD already has a port, devel/libgnugetopt, that does this. :) Great. I'll check this out. Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
Chris Costello wrote: What is the point of using GNU-getopt over the standard getopt other than --foo-bar flags that everyone I know hates? Hi, I'm Daniel. Pleased to meet you. Now you know someone who doesn't hate it. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] Everything journalists write is true, except when they write about something you know. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
On Mon, Jul 19, 1999, Daniel C. Sobral wrote: Chris Costello wrote: What is the point of using GNU-getopt over the standard getopt other than --foo-bar flags that everyone I know hates? Hi, I'm Daniel. Pleased to meet you. Now you know someone who doesn't hate it. Good morning, Daniel! As someone more helpful than myself in this thread has already pointed out, it seems, there is a port for the GNU getopt, known as 'libgnugetopt'. I would imagine this would help the thread's originator in porting the GNU utilities to FreeBSD. -- |Chris Costello [EMAIL PROTECTED] |Hardware: The parts of a computer system that can be kicked. ` To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM LDAP in FreeBSD
Following up on my own post:
For LDAP to be seamlessly integrated into the system some of the libraries
have to be changed. Specifically the ones dealing with /etc/passwd and
user information.
I've decided the best way to do this is to do what's done with NIS.
Basically handle the case where the user is not available in the local
databases.
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
^^^ ^^^ ^^^ ^^
| |||
portbase dnattr LDAP Server
This comes ftom a pam_ldap module I got from Pedro A M Vazquez
[EMAIL PROTECTED]
I'll change all of the function in lib/libc/gen/getpwent.c to handle this
special case.
The only problem is that openldap has to be integrated on the base system
for this to compile... can I safely copy it to /usr/src/contrib?
How do I submit this after it's done? anyone cares about ldap :)?
Regards,
-Oscar
On Thu, Jul 15, 1999 at 08:03:36PM -0600, Oscar Bonilla wrote:
While trying to use the pam_ldap module available from www.padl.com
I discovered the following problem.
although the module authenticates just fine (using openldap)
the login program fails to permit logins. I traced the problem to
login.c --- the following code is from login.c
my questions are at the bottom.
pwd = getpwnam(username);
- at this point pwd == NULL due to the fact that the user
- does not exist on the local passwd database... see below
/*
* if we have a valid account name, and it doesn't have a
* password, or the -f option was specified and the caller
* is root or the caller isn't changing their uid, don't
* authenticate.
*/
if (pwd != NULL) {
if (pwd-pw_uid == 0)
rootlogin = 1;
if (fflag (uid == (uid_t)0 ||
uid == (uid_t)pwd-pw_uid)) {
/* already authenticated */
break;
} else if (pwd-pw_passwd[0] == '\0') {
if (!rootlogin || rootok) {
/* pretend password okay */
rval = 0;
goto ttycheck;
}
}
}
fflag = 0;
(void)setpriority(PRIO_PROCESS, 0, -4);
#ifndef NO_PAM
/*
* Try to authenticate using PAM. If a PAM system error
* occurs, perhaps because of a botched configuration,
* then fall back to using traditional Unix authentication.
*/
if ((rval = auth_pam()) == -1)
- This returns PAM_SUCCESS since the pam_ldap module has
- successfully identified and authenticated the user.
#endif /* NO_PAM */
rval = auth_traditional();
(void)setpriority(PRIO_PROCESS, 0, 0);
#ifndef NO_PAM
/*
* PAM authentication may have changed "pwd" to the
* entry for the template user. Check again to see if
* this is a root login after all.
*/
if (pwd != NULL pwd-pw_uid == 0)
rootlogin = 1;
#endif /* NO_PAM */
ttycheck:
/*
* If trying to log in as root without Kerberos,
* but with insecure terminal, refuse the login attempt.
*/
- This next if is the problem: pwd == NULL from above,
- and the user doesn't get in.
if (pwd !rval) {
if (rootlogin !rootok)
refused(NULL, "NOROOT", 0);
else/* valid password authenticated */
break;
}
(void)printf("Login incorrect\n");
failures++;
1. what would be the right way to fix this?
2. after the user successfully logs in he still won't have an entry
in the /etc/passwd database, so all syscalls having to do with
identifying the user will fail... how can I have these funcions get
their info from LDAP?
I'm willing to patch and submit these programs, but would like some
feedback about the right way to integrate this.
I checked with a friend who uses linux, and it appears linux doesn't have
this problem since they use the
Re: softupdates on root partition, no floppy
If you boot single-user, root will be mounted read-only and you should be able to 'tunefs -n enable /dev/rda0a' and reboot. -Matt Matthew Dillon [EMAIL PROTECTED] It's a little bit simpler than that: in single user mode, tunefs -n enable / no reboot is necessary (tunefs reloads the fs after it makes changes on disk). -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
bug in ip_forward() ?
I suspect a bug in IP forwarding. I'm using FreeBSD 2.2.8-RELEASE.
This is our network:
+--+ +--+ +--+ +--+
| |4.2 4.1| |2.1 2.2| |5.1 5.2| |
|btm22t|-|btm22q|-|btm22r|-|btm22u|
| | | | | | | |
+--+ +--+ +--+ +--+
And this is what I do:
btm22t# ping 192.168.5.2
ok, it works...
btm22q# route delete -net 192.168.5.0 -netmask 255.255.255.252 192.168.2.2
ok, ping stops.
btm22q# route add -net 192.168.5.0 -netmask 255.255.255.252 192.168.2.2
ping doesn't work
btm22t# ^C
btm22t# ping 192.168.5.2
ping still doesn't work
btm22t# ping 192.168.5.1 (or 192.168.2.2)
this ping works and suddenly the ping to 192.168.5.2 works too !
Although:
btm22t# ping 192.168.5.2
ok, it works...
btm22t# ^C
btm22q# route delete -net 192.168.5.0 -netmask 255.255.255.252 192.168.2.2
btm22q# route add -net 192.168.5.0 -netmask 255.255.255.252 192.168.2.2
btm22t# ping 192.168.5.2
ping works!
After disabling the cache in ip_forward() (netinet/ip_input.c)
i.e.:
sin = (struct sockaddr_in *)ipforward_rt.ro_dst;
if ((rt = ipforward_rt.ro_rt) == 0 ||
ip-ip_dst.s_addr != sin-sin_addr.s_addr )
if (1)
{
...
the problem doesn't occur!
Anyone has a clue what's wrong here ?
Thanks a lot,
Wim.
---
What follows is just some background info.
Relevant routes:
btm22t:
192.168/30 198.149.4.1UGS1c 00 fxp0
192.168.1/30 198.149.4.1UGS1c 00 fxp0
192.168.2/30 198.149.4.1UGS1c 02 fxp0
192.168.4/30 link#2 UC 00
192.168.4.10:50:8b:7:50:12UHLW0 139
btm22q:
192.168/30 link#2 UC 00
192.168.0.1link#2 UHLW2 11
192.168.1/30 192.168.0.1UGS1c 00 fxp1
192.168.2/30 link#3 UC 00
192.168.2.20:8:c7:b3:c8:c3UHLW1 44 fxp2927
192.168.3/30 192.168.0.1UGS1c 00 fxp1
192.168.4/30 link#1 UC 00
192.168.4.20:50:8b:7:54:2eUHLW1 4534 fxp0777
192.168.5/30 192.168.2.2UGSc02 fxp2
btm22r:
192.168/30 192.168.1.1UGS1c 00 fxp2
192.168.1/30 link#3 UC 00
192.168.1.1link#3 UHLW1 103
192.168.2/30 link#2 UC 00
192.168.2.10:50:8b:7:49:17UHLW1 145 fxp1895
192.168.4/30 192.168.2.1UGS1c 1 21 fxp1
192.168.5/30 link#1 UC 00
192.168.5.20:50:8b:7:54:33UHLW0 275355 fxp0505
btm22u:
192.168.2/30 192.168.5.1UGS1c 0 16 fxp1
192.168.4/30 192.168.5.1UGS1c 06 fxp1
192.168.5/30 link#2 UC 00
192.168.5.10:50:8b:7:49:7dUHLW20 fxp1489
dmesg on btm22q:
FreeBSD 2.2.8-RELEASE #0: Fri Jul 16 15:34:52 CEST 1999
[EMAIL PROTECTED]:/usr/src/sys-cvs/sys/compile/CUSTOM
CPU: Pentium II (quarter-micron) (348.49-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x652 Stepping=2
Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,b16,b17,MMX,
b24
real memory = 67108864 (65536K bytes)
avail memory = 63123456 (61644K bytes)
altq: major number is 96
Probing for devices on PCI bus 0:
chip0 generic PCI bridge (vendor=8086 device=7190 subclass=0) rev 2 on pci0:0:0
chip1 generic PCI bridge (vendor=8086 device=7191 subclass=4) rev 2 on pci0:1:0
fxp0 Intel EtherExpress Pro 10/100B Ethernet rev 5 int a irq 11 on pci0:13:0
fxp0: Ethernet address 00:50:8b:07:50:12
fxp1 Intel EtherExpress Pro 10/100B Ethernet rev 5 int a irq 11 on pci0:14:0
fxp1: Ethernet address 00:50:8b:07:4b:f6
fxp2 Intel EtherExpress Pro 10/100B Ethernet rev 5 int a irq 11 on pci0:15:0
fxp2: Ethernet address 00:50:8b:07:49:17
chip2 generic PCI bridge (vendor=1011 device=0024 subclass=4) rev 3 on pci0:16:0
chip3 Intel 82371AB PCI-ISA bridge rev 2 on pci0:20:0
chip4 Intel 82371AB IDE interface rev 1 on pci0:20:1
chip5 Intel 82371AB USB interface rev 1 int d irq 11 on pci0:20:2
chip6 Intel 82371AB Power management controller rev 2 on pci0:20:3
Probing for devices on PCI bus 1:
vga0 VGA-compatible display device rev 1 int a irq 11 on pci1:0:0
Probing for devices on PCI bus 2:
de0 Digital 21140A Fast Ethernet rev 34 int a irq 11 on pci2:4:0
de0: ZNYX ZX34X 21140A [10-100Mb/s] pass 2.2
de0: address 00:c0:95:e0:e3:70
de1 Digital 21140A Fast Ethernet rev 34 int a irq 11 on pci2:5:0
de1: ZNYX ZX34X 21140A [10-100Mb/s]
Overcommit and calloc()
On the other hand, I find the discussion about the merits of overcommit and the (albeit not always in-depth) explanations of the FreeBSD VM system educational. It would be nice if would could just extract the small amount of signal from this discussion and put it into documentation somewhere. Also, it has got me thinking: does FreeBSD overcommit memory allocated by calloc()? Seems that it would be difficult since the page would have had to have been touched in order be zeroed, but I was curious. I'm afraid my question got lost amongst the see of overcommit messages. :) I was curious if calloc() was overcommitted also? Or is it more fundamental than that and the kernel always overcommits memory, which processes claim via sbrk, but which, when finally touched by the app, the kernel fills with a zero'ed page. If my scenario is correct, what affect does our malloc() algorithm have, if any...in other words, is there any way to reclaim memory which was returned to the heap via free(), but which malloc() can't sbrk back to the system? Does it matter? The scenario I think of is a process malloc()'ing a large amount of memory (which is implemented by increasing the process' address space via sbrk), then malloc()'ing another chunk of memory (again, sbrk'ing). Finally, freeing the memory allocated via the first call to malloc(). Now there is a large hole in the process' address space, which presumably will be backed by swap when in fact it is useless. I can't think of any way around that, nor can I imagine it is that great of a problem, but then again, I don't know everything :) I was curious what some of the gurus thought. Thanks, Kelly ~[EMAIL PROTECTED]~ FreeBSD - The Power To Serve - http://www.freebsd.org/ Join Team FreeBSD - http://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Determining the return address
Alfred Perlstein [EMAIL PROTECTED] writes: erm, can't you point multiple signal handler entries to the same routine? can't you also make it so that signals aren't defered or blocked while another handler is executing so you may actually re-enter the handler before it's complete. I use good ol' signal() rather than sigaction(), so no, signals can't interrupt one another's handlers. specifically how you say you increment it, then decrement it, if you have multiple handlers where one can interupt another you can have the counter get jumbled. Not if increment / decrement is atomic. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
(most of it are due to lack of a real getopt routine). FreeBSD does have a real, 100% posix compatible getopt. Maybe you are missing one of the numerous, non-standard Linux extentions? Gnu's getopt can be found in about a dozen different places in the FreeBSD tree. cvs, tar, etc. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
In message [EMAIL PROTECTED] Per Lundberg writes: : I know it isn't standard. But it works well, and is used by a lot of : programs. Perhaps it should have been put in another library than libc, : though. Actually, I'd better suggest this to the GNU people right ahead. There has been talking of having a libgnu.a to contain common routines like the long getopt... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
In message [EMAIL PROTECTED] Chris Costello writes: : getopt other than --foo-bar flags that everyone I know hates? Not everyone hates them... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
On Mon, 19 Jul 1999, Warner Losh wrote: There has been talking of having a libgnu.a to contain common routines like the long getopt... Yeah, I was thinking about something like that. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Overcommit and calloc()
"Kelly Yancey" [EMAIL PROTECTED] writes:
I'm afraid my question got lost amongst the see of overcommit messages. :)
I was curious if calloc() was overcommitted also?
Here's our calloc() implementation:
void *
calloc(num, size)
size_t num;
register size_t size;
{
register void *p;
size *= num;
if ( (p = malloc(size)) )
bzero(p, size);
return(p);
}
so the answer is yes, it overcommits, but the bzero() may cause the
system to run out of swap.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM LDAP in FreeBSD
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. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] 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: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? -Oscar -- For PGP Public Key: finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM LDAP in FreeBSD
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 DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM LDAP in FreeBSD, and userfs too.
I thought now would be a good time to chime in on some of my wild schemes... The reason I am interested in 'userfs' is to enable me to write a version of 'nsd'. Those of you familiar with Irix will recognize it. For others, what it does is to present the name-space on a machine as filespace. The advantages of this is that we can greatly simplify out libc to use the file/namespace that nsd provides. For example 'getpwent()' now becomes file accesses to /ns/.local/passwd/NAME. Another advantage that this abstraction provides is that it allows transparent alterations of the databases in use, even to the extent of NOT having to restart each client that may be using a specific database. -- David Cross | email: [EMAIL PROTECTED] Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Overcommit and calloc()
Ahh...but wouldn't the bzero() touch all of the memory just allocated
functionally making it non-overcommit? I realize that technically it isn't
the same since although calloc() would ensure the memory actually was
committed (again, since the bzero() touches all the pages), if there weren't
enough pages free then a random process would still be killed rather than
returning null.
Believe me, I'm not trying to start that war again :) I'm just pointing
out that while technically it is still overcommit, it will touch the pages
ensuring that the memory does in fact exist (is committed). Perhaps this is
why I've always heard we should avoid calloc() because it is 'slow'?
Thanks for the great feedback, I should kick myself for now digging my
hands in the mud myself (I assumed it was more complicated than that :) ).
Kelly
~[EMAIL PROTECTED]~
FreeBSD - The Power To Serve - http://www.freebsd.org/
Join Team FreeBSD - http://www.posi.net/freebsd/Team-FreeBSD
-Original Message-
From: Dag-Erling Smorgrav [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 19, 1999 12:07 PM
To: Kelly Yancey
Cc: [EMAIL PROTECTED]
Subject: Re: Overcommit and calloc()
"Kelly Yancey" [EMAIL PROTECTED] writes:
I'm afraid my question got lost amongst the see of overcommit
messages. :)
I was curious if calloc() was overcommitted also?
Here's our calloc() implementation:
void *
calloc(num, size)
size_t num;
register size_t size;
{
register void *p;
size *= num;
if ( (p = malloc(size)) )
bzero(p, size);
return(p);
}
so the answer is yes, it overcommits, but the bzero() may cause the
system to run out of swap.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Overcommit and calloc()
"Kelly Yancey" [EMAIL PROTECTED] writes: Ahh...but wouldn't the bzero() touch all of the memory just allocated functionally making it non-overcommit? No. If it were an "non-overcomitting malloc", it would return NULL and set errno to ENOMEM, instead of dumping core. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Overcommit and calloc()
In the last episode (Jul 19), Dag-Erling Smorgrav said: "Kelly Yancey" [EMAIL PROTECTED] writes: Ahh...but wouldn't the bzero() touch all of the memory just allocated functionally making it non-overcommit? No. If it were an "non-overcomitting malloc", it would return NULL and set errno to ENOMEM, instead of dumping core. It should be possible to modify calloc to trap signals, then bzero. If bzero faults, you free the memory and return NULL. No, wait. You can't trap SIGKILL. How about this. mmap() some anonymous memory MAP_SHARED, fork a child to bzero it. If the child dies, unmmap and return NULL. If the child succeeds, use the memory. This memory won't be freeable with malloc(), though. -Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
On Mon, 19 Jul 1999, Per Lundberg wrote: On Mon, 19 Jul 1999, Alex Zepeda wrote: It's quite easily argued that depending on a *NON STANDARD* getopt routine is a bug. I know it isn't standard. But it works well, and is used by a lot of programs. Perhaps it should have been put in another library than libc, though. Actually, I'd better suggest this to the GNU people right ahead. If you give me documentation on it, I'll implement it for the BSD libc. It would be nice to go in, perhaps as a weak symbol (to remain compatible with FreeBSD packages including their own getopt.) And don't tell me to look at the getopt long code itself. That stuff is sickening. I just want the [exact] API. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
On Mon, 19 Jul 1999, Warner Losh wrote: In message [EMAIL PROTECTED] Per Lundberg writes: : I know it isn't standard. But it works well, and is used by a lot of : programs. Perhaps it should have been put in another library than libc, : though. Actually, I'd better suggest this to the GNU people right ahead. There has been talking of having a libgnu.a to contain common routines like the long getopt... How about libcompat/gnu/? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ 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 [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: glibc
In article [EMAIL PROTECTED], Brian F. Feldman [EMAIL PROTECTED] wrote: [GNU getopt] If you give me documentation on it, I'll implement it for the BSD libc. Note, we already have GNU getopt in the source tree in libiberty (in two different places -- binutils and gdb). It might be better just to install libiberty from one of those places. Left as an exercise for the reader: Figure out how the two differ and which one is "better". :-) John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
On Mon, 19 Jul 1999, John Polstra wrote: In article [EMAIL PROTECTED], Brian F. Feldman [EMAIL PROTECTED] wrote: [GNU getopt] If you give me documentation on it, I'll implement it for the BSD libc. Note, we already have GNU getopt in the source tree in libiberty (in two different places -- binutils and gdb). It might be better just to install libiberty from one of those places. But it would be nice to have a free long getopt implementation. Left as an exercise for the reader: Figure out how the two differ and which one is "better". :-) I'd rather hurt myself severely. Wait a second, that's exactly what I'd be doing in the first place to do what you asked! Hm John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
Brian F. Feldman wrote: On Mon, 19 Jul 1999, John Polstra wrote: Left as an exercise for the reader: Figure out how the two differ and which one is "better". :-) I'd rather hurt myself severely. Of course. That's a prerequisite for becoming a committer. :-) John --- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
Mike Smith wrote: The loader will, at some stage in the future, grow a persistent data store in which items like this can be saved. Doesn't /boot/[defaults/]loader.conf[.local] qualify as persistent data storage? There is little or no chance that the loader will gain the ability to write back to filesystems. Some of them don't support it (eg. iso9660), others may not (TFTP, NFS), and the code required for some of them (especially UFS) would be problematically large. But that's okay. If the persistent storage is the loader conf files, they can be updated from single or multi-user mode. There are cases where they need to be updated _by_the_loader_; see eg. the "nextboot" manpage for functionality that we have currently lost. So much the better. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bug in ip_forward() ?
Wim Livens wrote: I suspect a bug in IP forwarding. I'm using FreeBSD 2.2.8-RELEASE. This is our network: +--+ +--+ +--+ +--+ | |4.2 4.1| |2.1 2.2| |5.1 5.2| | |btm22t|-|btm22q|-|btm22r|-|btm22u| | | | | | | | | +--+ +--+ +--+ +--+ And this is what I do: btm22t# ping 192.168.5.2 ok, it works... btm22q# route delete -net 192.168.5.0 -netmask 255.255.255.252 192.168.2.2 ok, ping stops. btm22q# route add -net 192.168.5.0 -netmask 255.255.255.252 192.168.2.2 ping doesn't work And it shouldn't, you haven't given it an appropriate route. From route(8): The other commands have the following syntax: route [-n] command [-net | -host] destination gateway where destination is the destination host or network, gateway is the next-hop intermediary via which packets should be routed. There's the important part right there: gateway is the *next-hop* intermediary via which packets should be routed. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: softupdates on root partition, no floppy
If you boot single-user, root will be mounted read-only and you should be able to 'tunefs -n enable /dev/rda0a' and reboot. -Matt Matthew Dillon [EMAIL PROTECTED] It's a little bit simpler than that: in single user mode, tunefs -n enable / no reboot is necessary (tunefs reloads the fs after it makes changes on disk). Unfortunately it doesn't first check to see if the fs is already loaded (so the reload generates a scary error message on all the other fs'es). -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Sv: softupdates on root partition, no floppy
From: Stephen McKay [EMAIL PROTECTED] On Saturday, 17th July 1999, Matthew Dillon wrote: :Is there any way to force softupdate on on a mounted system, or do I have to :either move the / to another machine, or move a floppydrive to this machine? If you boot single-user, root will be mounted read-only and you should be able to 'tunefs -n enable /dev/rda0a' and reboot. I gave up using soft updates on root because of the delayed delete behaviour. I kept filling up root while updating kernels. It doesn't gain you much on little used file systems anyway. So, I recommend people leave root alone. Well, this disk is 4G and has only one partition, containing both / and /usr, so I think I may benefit from softupdates. Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM LDAP in FreeBSD, and userfs too.
On Mon, Jul 19, 1999 at 12:29:48PM -0400, David E. Cross wrote: I thought now would be a good time to chime in on some of my wild schemes... The reason I am interested in 'userfs' is to enable me to write a version of 'nsd'. Those of you familiar with Irix will recognize it. For others, what it does is to present the name-space on a machine as filespace. The advantages of this is that we can greatly simplify out libc to use the file/namespace that nsd provides. For example 'getpwent()' now becomes file accesses to /ns/.local/passwd/NAME. Another advantage that this abstraction provides is that it allows transparent alterations of the databases in use, even to the extent of NOT having to restart each client that may be using a specific database. Lovely. Sounds like a much better way to do the Solaris/Linux (and NetBSD?) /etc/nsswitch.conf stuff. On Solaris at least, this is implemented using masses of weird shared objects... -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM LDAP in FreeBSD
Mike Smith wrote: 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? Use PAM. PAM isn't going to cut it. This is outside of its realm. Things like ps, top, ls, chown, chmod, lpr, rcmd, who, w, (the list goes on) need to be able to pull 'passwd' entries from the LDAP server, and unless we PAM all of those (I think that is a very bad idea), then a person will be able to login but will be dead in the water without a UID -Username mapping. -- David Cross | email: [EMAIL PROTECTED] Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM LDAP in FreeBSD, and userfs too.
On Mon, 19 Jul 1999 20:44:18 +0100 Dominic Mitchell [EMAIL PROTECTED] wrote: Lovely. Sounds like a much better way to do the Solaris/Linux (and NetBSD?) /etc/nsswitch.conf stuff. On Solaris at least, this is implemented using masses of weird shared objects... The plan for NetBSD is that things will also be handled with dynamic modules, but those dynamic modules will be glued into a `nscd'[*] (if you use Solaris, you're familiar with the name :-). [*] We are planning on not having all of the problems that the Solaris nscd has, and that people often complain about. This will allow libc to simply make a call to nscd (or fallback onto traditional `files' lookup), and nscd will handle all but the `files' case. This allows system-wide caching, and puts all of the complexity in one place. Involving one or more user mode file systems seems like ... the wrong approach for a name service switch. -- Jason R. Thorpe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Anything special with kmem_map and mb_map?
I have been wondering this for some time. There are many kernel submaps: exec_map, clean_map, etc. But if you look the code in vm_map_find(), we have to call splvm() for kmem_map and its submap mb_map, but not for other kernel submaps. So is there anything special with these two kernel submaps? Thanks for any help. -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Overcommit and calloc()
-Original Message- From: Dan Nelson [mailto:[EMAIL PROTECTED]] Sent: Monday, July 19, 1999 12:55 PM To: Dag-Erling Smorgrav Cc: Kelly Yancey; [EMAIL PROTECTED] Subject: Re: Overcommit and calloc() In the last episode (Jul 19), Dag-Erling Smorgrav said: "Kelly Yancey" [EMAIL PROTECTED] writes: Ahh...but wouldn't the bzero() touch all of the memory just allocated functionally making it non-overcommit? No. If it were an "non-overcomitting malloc", it would return NULL and set errno to ENOMEM, instead of dumping core. It should be possible to modify calloc to trap signals, then bzero. If bzero faults, you free the memory and return NULL. No, wait. You can't trap SIGKILL. How about this. mmap() some anonymous memory MAP_SHARED, fork a child to bzero it. If the child dies, unmmap and return NULL. If the child succeeds, use the memory. This memory won't be freeable with malloc(), though. Hrm. I'm not actually trying to get my system to not overcommit memory. I like overcommit. Besides, every process would have to trap SIGKILL (if you even could) to simulate a non-overcommit system because any process could be killed, not just the one requesting the memory, right? Really, I was just on an educational quest. I was curious to exactly how calloc() was implemented and what affect that had on our overcommit policy. DES was nice enough to show me that calloc() is just a malloc()+bzero() so effectively, the memory gets 'committed' because all of the pages are touched immediately after the malloc(). Whether or not a process get's shot is another matter entirely. :) I have another post on this list which begs the question: if memory given to us fro sbrk() is already zeroed, why zero it again if we don't have too if we make calloc() smarter, we could save come clock cycles. The real question is, how many? A quick scan (not exact) of the number of times calloc() is called yields: $ cd /usr/src $ t=0; grep -c -h -R "calloc" * | while read n; do let t+=$n; echo $t; done | tail -1 828 $ t=0; grep -c -h -R "malloc" * | while read n; do let t+=$n; echo $t; done | tail -1 11380 (of course, they each are a little high due to comments and the actual function definitions themselves; cavaet emptor) So calloc() is only used about 1/14th as often as malloc(), and considering many of those calloc() calls would still be serviced the same was a malloc() (reusing memory already on the heap and bzero()'ing it), I'm not 100% sure if the added complexity if worth the performance improvement. If it is, I'de be glad to "whip" some patches up for it (it really shouldn't be too hard). Kelly ~[EMAIL PROTECTED]~ FreeBSD - The Power To Serve - http://www.freebsd.org/ Join Team FreeBSD - http://www.posi.net/freebsd/Team-FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Overcommit and calloc()
From: Kelly Yancey [mailto:[EMAIL PROTECTED]] I have another post on this list which begs the question: if memory given to us fro sbrk() is already zeroed, why zero it again if we don't have too if we make calloc() smarter, we could save come clock cycles. Because the memory returned from malloc() might be from a previous malloc()/free() and may be dirty. Charles To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM LDAP in FreeBSD, and userfs too.
Lovely. Sounds like a much better way to do the Solaris/Linux (and NetBSD?) /etc/nsswitch.conf stuff. On Solaris at least, this is implemented using masses of weird shared objects... The plan for NetBSD is that things will also be handled with dynamic modules, but those dynamic modules will be glued into a `nscd'[*] (if you use Solaris, you're familiar with the name :-). [*] We are planning on not having all of the problems that the Solaris nscd has, and that people often complain about. This will allow libc to simply make a call to nscd (or fallback onto traditional `files' lookup), and nscd will handle all but the `files' case. This allows system-wide caching, and puts all of the complexity in one place. Involving one or more user mode file systems seems like ... the wrong approach for a name service switch. Tomato, Tomatoe. The difference between the 2 methods is in their interaction with the database itself. You will be providing a socket-ish interface to the cache, my plan is for a filesystem interface, heck it could probably do both. I personally prefer the FS approach in dealing with both on Solaris and Irix. What Irix does well, Irix does very well. The FS method also allows more complex permission checking on access to various databases, like shadow, because the node in a directory had the added granularity of being group readable. It also gives you the flexibility of the shell, or a web-browser, to get at the data. Another idea I had considered was placing something ala 'rc.conf' into a database to allow easy distribution throughout many computers (this would obviously be configuration later in the boot process). Having a FS style interface makes it much easier for programs to get at the data in a clear, consistent manor. These are just my ramblinngs, and it seems we are quickly converging on the same basic idea with slightly different (but perhaps compatible) implementations. -- David Cross | email: [EMAIL PROTECTED] Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
speed of file(1)
While trying to port amavis, the virusscanner for mail, http://aachalon.de/AMaViS/amavis-0.2.0-pre4.tar.gz ) I noticed it used the file(1) several times for each file, and it took rather long time, causing bb to report red for high CPU-load each time I collected a batch of mail. So I compared it with a Linux box: My 60MHz Pentium, FreeBSD time file /usr/home/leif/vnc-3.3.2r /usr/home/leif/vnc-3.3.2r3_unixsrc.tgz: gzip compressed data, deflated, original filename, last modified: Thu Jan 21 19:23:21 1999 real0m1.237s user0m0.758s sys 0m0.394s 133MHz Pentium II, Linux time file vnc-3.3.2r3_unixsrc.tgz vnc-3.3.2r3_unixsrc.tgz: gzip compressed data, deflated, original filename, last modified: Thu Jan 21 19:23:21 1999, os: Unix real0m0.036s user0m0.010s sys 0m0.030s While I realise 60MHz is less than 133MHz, a factor 34 in difference of real time seems suspect. The magic file is different, but almost the same size. Why is FreeBSD's file so much slower? Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: RE: Overcommit and calloc()
:From: Kelly Yancey [mailto:[EMAIL PROTECTED]] :I have another post on this list which begs the question: if memory given :to us fro sbrk() is already zeroed, why zero it again if we don't have :too if we make calloc() smarter, we could save come clock cycles. : :Because the memory returned from malloc() might be from a previous :malloc()/free() and may be dirty. : :Charles malloc() uses madvise( ... MADV_FREE) heavily in order to reduce the number of page faults that need to be taken through the course of a program's operation. MADV_FREE is an advisory free that causes FreeBSD to mark the underlying page(s) clean and to free any associated swap backing store. The kernel avoids actually freeing the page until it needs the memory, and the process can re-dirty the page to keep it. No new page-faults occur if the kernel has not reclaimed the page at the time the process reuses it. If the kernel reclaims the page first, the kernel replaces it with zero-fill. If the process reclaims the page first, the page's previous contents (considered to be 'garbage') are retained. Thus, calloc() cannot under normal circumstances assume that the data buffer returned by malloc() is already clear. Since calloc() is not usually used to allocate large chunks of memory, this isn't a problem. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On Mon, 19 Jul 1999, Reinier Bezuidenhout wrote: Hi .. 1. If you want to test the network speed ... use ttcp or something that generates the data and doesn't read it from disk. ttcp works. The only problem is when I tried it in both directions, at once. the total becomes 11.xMbytes/sec total as opposed to 9.4Mbytes/sec when doing it in one direction only. If the devices are set at full-duplex then you are looking at something else ... the standard size for ttcp packets is 8k ... maybe the switch etc. that you are connected to doesn't handle fragmented packets very well. Hmmm, the thing is we replaced the cables with pre-made ones that go directly from the machines to the Cisco Catalyst 2924XL switch. Ofcourse, the switch is on 10/100 Auto-negotiation. But ... what it rather seems like .. is that the devices are not in full-duplex mode generating a lot of collisions. After a test with transfers in both directions .. check the number of collisions with "netstat -in". If the number of collisions is not high .. - wait a moment ... are you using ttcp with tcp or udp option ... if you are using tcp (the default) then when transfering data you have acks going in both directions which could cause collisions on a full-duplex line ... try the same with the -u option for UDP. Check our setup below ... I'll explain some things there. I was using ttcp in two separate instances, one for send and one for receive between the same two machines. I did ttcp -r -s and the other end was ttcp -s -r. Also check with "netstat -sn" to see if there are any other counters that increase with the full-duplex transfers. Will do that. 2. When doing full-duplex and using fxp cards, stay away from X-over cables ... use a full-duplex switch etc. ... the fxp cards are not made to work with X-over cables (as far as I know - ala Intel spec) note ... only for full-duplex tests. Does anyone actually use X-over cables for 100Mbps Full Duplex since 3Com said CrossOver cables are not rated for 100Mbps or something even though it's Cat5. Actually, in the older Intel docs for the Pro100B, it does say to connect using X-over cable to the switch. Yes ... to a switch maybe ... but not fxp to fxp ... when transfering small packets .. you get a lot of "device timeouts". I thought from a fxp to a fxp, you will need a x-over since a straight-wire won't work. We have done tests in full-duplex with non Intel cards (because we did not have a switch at that time :)) and with max size packets we got around 188.00 Mbps using the de0 driver. Pretty interesting. How did you do the full duplex tests? I'll describe the setup briefly ... :) We had 3 machines two PII-400 as the generators and a PII-400 as the machine in the middle ... So we have a setup that looks like this ... - -- - | Gen 1 |-| Router |-| Gen 2 | - -- - Now .. here is a trick ... add entries manually in the Router's tables to simulate machines on each side that "does not exist". The reason for this is that we don't want the machines on the side to be generating AND excepting packets ... we just want them to generate packets at max network rate and nothing else. We then start a ttcp on both sides to the "non existing" machines. This means the router will be forwaring packets it receives without any machines having to be there because of the entries in the routing table. (we did this because we did not have another two fast machines at that time, but we did check the packets to make sure everything goes through and are not dropped etc. - it was some time ago :) ) We start ttcp with the following command ttcp -t -s -u -p 7000 -n nice large number -l 1472 10.0.0.1 the size of 1472 generates nice 1514 size UDP packets :) We then let the test run ... and check the throughput ... We used CAT5 X-over cables ... Hopw this helps Ah, I guess you didn't test it on a actual network that's connected to the world and also it was a direct connection between the machines rather than through a switch that can be congested. Cheers, Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: speed of file(1)
Check the size of the magic files on your FreeBSD and Linux boxen. file was never really designed to be efficient. FreeBSD's magic file is /usr/share/misc/magic - around 164K. -Matt : :While trying to port amavis, the virusscanner for mail, : http://aachalon.de/AMaViS/amavis-0.2.0-pre4.tar.gz ) I noticed it used the :file(1) several times for each file, and it took rather long time, causing :bb to report red for high CPU-load each time I collected a batch of mail. : :So I compared it with a Linux box: : :My 60MHz Pentium, FreeBSD : :time file /usr/home/leif/vnc-3.3.2r :/usr/home/leif/vnc-3.3.2r3_unixsrc.tgz: gzip compressed data, deflated, :original filename, last modified: Thu Jan 21 19:23:21 1999 : :real0m1.237s :user0m0.758s :sys 0m0.394s : :133MHz Pentium II, Linux : :time file vnc-3.3.2r3_unixsrc.tgz :vnc-3.3.2r3_unixsrc.tgz: gzip compressed data, deflated, original filename, :last modified: Thu Jan 21 19:23:21 1999, os: Unix : :real0m0.036s :user0m0.010s :sys 0m0.030s : :While I realise 60MHz is less than 133MHz, a factor 34 in difference of real :time seems suspect. : :The magic file is different, but almost the same size. : :Why is FreeBSD's file so much slower? : :Leif : : : : :To Unsubscribe: send mail to [EMAIL PROTECTED] :with "unsubscribe freebsd-hackers" in the body of the message : Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anything special with kmem_map and mb_map?
:I have been wondering this for some time. There are many kernel :submaps: exec_map, clean_map, :etc. But if you look the code in vm_map_find(), we have to call splvm() :for kmem_map and its :submap mb_map, but not for other kernel submaps. So is there anything :special with these two :kernel submaps? : :Thanks for any help. : :-Zhihui The kmem_map and mb_map's can be modified from interrupts. The other maps cannot. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Simple parallel debugger
If you have needed to monitor and control lots of processes on e.g. a cluster I have rereleased a tool for this purpose. It is called simple parallel debugger, or SPD. Please if interested go to www.acl.lanl.gov/~rminnich and follow the link under that title. I know this is a bit old but I have yet to see a counterpart elsewhere that is freely available. Comments, questions, suggestions are most welcome. Thanks ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Determining the return address
Dag-Erling Smorgrav [EMAIL PROTECTED] wrote: Alfred Perlstein [EMAIL PROTECTED] writes: specifically how you say you increment it, then decrement it, if you have multiple handlers where one can interupt another you can have the counter get jumbled. Not if increment / decrement is atomic. Which it _isn't_ in general. The only case where it _is_ atomic is on a UP i386, where the compiler has generated an `inc' instruction (which it might not). Check out /sys/alpha/include/atomic.h or a recent (less than a week old [1]) -current version of /sys/i386/include/atomic.h for atomic code. Peter [1] It was broken prior to this. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM LDAP in FreeBSD
ldap:*:389:389:o=My Organization, c=BR:uid:ldap.myorg.com Horrible idea. suggestions? Use PAM. PAM isn't going to cut it. This is outside of its realm. Things like ps, top, ls, chown, chmod, lpr, rcmd, who, w, (the list goes on) need to be able to pull 'passwd' entries from the LDAP server, and unless we PAM all of those (I think that is a very bad idea), then a person will be able to login but will be dead in the water without a UID -Username mapping. The Linux-PAM folks solved this with their 'libpwdb', which basically provides a transport-neutral interface to the whole uid:userdata mapping. Unfortunately, their implementation _reeks_, so nobody has touched it yet. This is, however, how I think we should be going. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Sv: speed of file(1)
From: Matthew Dillon [EMAIL PROTECTED] Check the size of the magic files on your FreeBSD and Linux boxen. file was never really designed to be efficient. FreeBSD's magic file is /usr/share/misc/magic - around 164K. -Matt : : :The magic file is different, but almost the same size. : Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM LDAP in FreeBSD
Keith Stevenson wrote: 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? /etc/pam.conf would be appropriate for configuring the behavior of PAM modules. /etc/auth.conf would be appropriate for configuring WHICH authentication method to use. Let's please don't confuse the two. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM LDAP in FreeBSD
On Fri, Jul 16, 1999 at 12:36:48PM -0600, Oscar Bonilla wrote: For LDAP to be seamlessly integrated into the system some of the libraries have to be changed. Specifically the ones dealing with /etc/passwd and user information. ... I haven't seen him post to this thread yet, but you might want to talk to Amancio Hasty [EMAIL PROTECTED]. I know he's been working with LDAP and FreeBSD. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM LDAP in FreeBSD
Mike Smith wrote: ldap:*:389:389:o=My Organization, c=BR:uid:ldap.myorg.com Horrible idea. suggestions? Use PAM. PAM isn't going to cut it. This is outside of its realm. Things like ps, top, ls, chown, chmod, lpr, rcmd, who, w, (the list goes on) need to be able to pull 'passwd' entries from the LDAP server, and unless we PAM all of those (I think that is a very bad idea), then a person will be able to login but will be dead in the water without a UID -Username mapping. The Linux-PAM folks solved this with their 'libpwdb', which basically provides a transport-neutral interface to the whole uid:userdata mapping. Unfortunately, their implementation _reeks_, so nobody has touched it yet. This is, however, how I think we should be going. 100% agreement here. This needs to be implemented such that the administrator configures the box to use local files, or NIS, or LDAP, or whatever as the source of username information, and both login(1) and ls(1) use the information as appropriate. For ls(1) and friends, this means implementing getpwuid(3) (and getgrgid(3)) so they "just work." The implementation details are as unimportant as ever: they have to work and be maintainable. Following prior art remains a good idea; the Solaris "name service switch" implementation is a good starting point to consider. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How much memory do we need to install?
On Mon, Jul 19, 1999 at 05:34:07PM +0930, Greg Lehey wrote: AFAIK, the minimum memory for installation is still 5 MB, and the problems people had with 8MB machines failing to install was a bug, right? What's the current status? Some people have reported that they need up to 12MB to install. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
maxfiles == maxfilesperproc ?
hax0rs, In sys/conf/param.c (in -STABLE), both maxfiles and maxfilesperproc are set equal to MAXFILES. This doesn't make much sense to me. It seems that maxfiles should be set to be greater than maxfilesperproc by default, so that one process can't consume all of the file descriptors. I noticed this while building a system that will be running some very large processes with many open files, so set maxfilesperproc on that box equal to MAXFILES - 512, but this metric is not appropriate for systems with small MAXUSERS (like GENERIC). So... 1. Should maxfiles be, by default, larger than maxfilesperproc? 2. If so, how much is necessary and appropriate? Regards, Greg -- Gregory S. Sutter "How do I read this file?" mailto:[EMAIL PROTECTED]"You uudecode it." http://www.pobox.com/~gsutter/ "I I I decode it?" PGP DSS public key 0x40AE3052 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: m68k Support in FreeBSD
website (http://www.freebsd.org/~green/FreeBSD-68k.txt). In about two weeks I'll have a spare Macintosh IIsi and would like to have a run at FreeBSD on it. So, to the point, where can I get it? :) I'd say that's a question for Grant Stockly, the person mentioned in green's web-cited message. It's certainly not part of FreeBSD and whether it ever will be is a matter still subject to debate. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: m68k Support in FreeBSD
On Mon, 19 Jul 1999, Jordan K. Hubbard wrote: website (http://www.freebsd.org/~green/FreeBSD-68k.txt). In about two weeks I'll have a spare Macintosh IIsi and would like to have a run at FreeBSD on it. So, to the point, where can I get it? :) I'd say that's a question for Grant Stockly, the person mentioned in green's web-cited message. It's certainly not part of FreeBSD and whether it ever will be is a matter still subject to debate. Isn't it more a question of whether a proper cross-build system will be available within the time frame that m68ks aren't completely obsolete? - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: m68k Support in FreeBSD
On Mon, 19 Jul 1999, Jordan K. Hubbard wrote: website (http://www.freebsd.org/~green/FreeBSD-68k.txt). In about two weeks I'll have a spare Macintosh IIsi and would like to have a run at FreeBSD on it. So, to the point, where can I get it? :) I'd say that's a question for Grant Stockly, the person mentioned in green's web-cited message. It's certainly not part of FreeBSD and whether it ever will be is a matter still subject to debate. Isn't it more a question of whether a proper cross-build system will be available within the time frame that m68ks aren't completely obsolete? No. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM LDAP in FreeBSD
On Mon, 19 Jul 1999, Wes Peters wrote: Given that this is a PAM module, wouldn't /etc/pam.conf be more appropriate? /etc/pam.conf would be appropriate for configuring the behavior of PAM modules. /etc/auth.conf would be appropriate for configuring WHICH authentication method to use. Let's please don't confuse the two. In my work on modularizing crypt() (which is almost ready for another alpha release) I'm using login classes in /etc/login.conf instead of system-global settings in /etc/auth.conf to decide password hash schemes. Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAO
In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: pertinent data: FreeBSD 3.2R on a SONY VAIO laptop, PAO3-19990605 version I just installed PAO on my SONY VAIO in hopes of getting my 3COM 3CXE589ET PCMCIA eithernet card working. When I boot the laptop with the PAO install floppies it finds the card and it works because I was able to download the PAO distributions from the FTP site through it. However when I reboot the system after the install I get the following errors. Maybe your kernel is still GENERIC kernel. Please try # cd / # chflags noschg kernel # cp kernel.PAO kernel # chflags schg kernel and reboot. If there's not kernel.PAO file, paobin has not successfly installed yet. -- HOSOKAWA, Tatsumi Assistant Manager Information Technology Center, Keio University [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
PAO
NB: Please reply to me directly, I'm not on the list pertinent data: FreeBSD 3.2R on a SONY VAIO laptop, PAO3-19990605 version I just installed PAO on my SONY VAIO in hopes of getting my 3COM 3CXE589ET PCMCIA eithernet card working. When I boot the laptop with the PAO install floppies it finds the card and it works because I was able to download the PAO distributions from the FTP site through it. However when I reboot the system after the install I get the following errors. - - - Initial rc.pccard configuration: pcic-memory=0xd pccardc: /dev/card0: Device not configured execute pccardd pccard-beep=2 pccardc: /dev/card0: Device not configured . Doinf initial network setup: hostname. ifconfig: interface ep0 does not exist ifconfig: interface ep0 does not exist lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet 127.0.0.1 netmask 0xff00 route: writing to routing socket: Network is unreachable - - - Typical startup stuff follows then syslogd pukes with the error. syslogd: syslog/udp: unknown service syslogd: child pid 107 exited with return code 1 I'm sure I've missed somthing stupid but I can see it. I can get a 3com 3c589 as listed in the release notes as a last resort. Does anybody have one of these working? thanks in advance for any help. -- Geoffrey Robinson 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 04:51:12PM -0600, Wes Peters wrote: The implementation details are as unimportant as ever: they have to work and be maintainable. Following prior art remains a good idea; the Solaris "name service switch" implementation is a good starting point to consider. I agree. In solaris (and linux by the way) all you do is set passwd ldap files in /etc/nsswitch.conf and that's it. I had started to write the code to mess with libc to "fix" the getpwent stuff, but a better solution is to "port" the nsswitch stuff from linux (i don't have source from solaris :) Anyone more knowledgeable should give me a big hand here and point me to the right way to start this. I'm willing to do the coding but need help on the overall design. Since I need this working asap, I'm gonna hack libc so that if the file /etc/auth.conf has a line saying auth_list = ldap, it looks in /etc/ldap.conf to get the rest of the stuff (server, port, base dn, etc). At the same time, we should work towards a real solution. regards, -Oscar -- For PGP Public Key: finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: m68k Support in FreeBSD
On Mon, 19 Jul 1999, Brian F. Feldman wrote: Isn't it more a question of whether a proper cross-build system will be available within the time frame that m68ks aren't completely obsolete? Bah! An 040 or 030 powered Mac w/ MacOS makes a decent web browsing, word processing machine; it's an actually useable alternative to an e-machine. Similarlly a 386 or 486 powered FreeBSD machine can still be quite useful even as a small server (admittedly the 68k Mac hardware makes for a piss poor server.. but still). I can't see a 486 or 040 powered machine becomming entirely obsolete until X is required to buildworld. - alex You better believe that marijuana can cause castration. Just suppose your girlfriend gets the munchies! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: softupdates on root partition, no floppy
On Mon, Jul 19, 1999 at 05:25:06PM +1000, a little birdie told me that Stephen McKay remarked I gave up using soft updates on root because of the delayed delete behaviour. I kept filling up root while updating kernels. It doesn't gain you much on little used file systems anyway. So, I recommend people leave root alone. No, don't leave it alone, make it even SLOWER than usual! /dev/da0s1a on / (local, synchronous, writes: sync 114 async 3850) Question of the day: Why do I have async writes on a sync partition? -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ FutureSouth Communications |ISPHelp ISP Consulting "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: softupdates on root partition, no floppy
On Mon, 19 Jul 1999, Matthew D. Fuller wrote: No, don't leave it alone, make it even SLOWER than usual! /dev/da0s1a on / (local, synchronous, writes: sync 114 async 3850) Question of the day: Why do I have async writes on a sync partition? Because only meta-data writes are done synchronously. Data is still done asynchronously. David Scheidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: softupdates on root partition, no floppy
On Mon, Jul 19, 1999 at 11:25:16PM -0500, a little birdie told me that David Scheidt remarked On Mon, 19 Jul 1999, Matthew D. Fuller wrote: Question of the day: Why do I have async writes on a sync partition? Because only meta-data writes are done synchronously. Data is still done asynchronously. Even with SYNC mounts? (Not 'default', explicit 'sync'. It takes quite noticeable amounts of time to, for instance, install kernels.) From fstab: # DeviceMountpoint FStype Options DumpPass# /dev/da0s1a / ufs rw,sync 1 1 -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ FutureSouth Communications |ISPHelp ISP Consulting "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USFS (User Space File System)
David, Unless I am misunderstanding you, mfs does what you are describing. --John "David E. Cross" [EMAIL PROTECTED] wrote: I am looking at a project that will require a user based process to interact with the system as if it were a filesystem. The traditional way I have seen this done is as the system NFS mounting itself (ala AMD). I would really lik e a more clean approach to this. What I am interested in is a 'User Space File System' that would interact with a user process in a similiar manor to how nfsd's do. A process would issue a mount (ok, this is different than NFSDs), then it would make a special system call with a structure, that call would return whenever a request was pending with the structure filled in with the appropriate information. The user process would fulfill the request , pack the return data into the structure and call kernel again. I have a number of questions on more specific ideas (like caching, inode/vnod e interaction, etc). But I am just feeling arround for what people think about this. Any ideas/comments? -- David Cross | email: [EMAIL PROTECTED] Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~cross d Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: tee option on ipfw?
The 'tee' behavior can be pretty easily emulated, however. a) use bpfilter - it automatically does a copy type thing. b) Use a little divert socket program which simply does: len = recvfrom(divert_socket, packetbuf, sizeof(packetbuf), 0, (struct sockaddr *)from, fromlen); sendto(divert_socket, packetbuf, len, 0, (struct sockaddr *)from, fromlen); do_whatever_stuff_you_want(); Option a will, of course, be faster, since it doesn't involve a copy to userspace before allowing the packet to continue its normal path. The tee option would do the same thing, if and when. -Dave Lo and behold, Jaye Mathisen once said: The man page says the tee option on ipfw is not yet supported. I'm wondering if that is still the case as of 3.2-stable, or if the doc is just out of date. I would like to make a copy of incoming UDP packets to a specific port for some testing. tee seems like an easy way to go. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- work: [EMAIL PROTECTED] me: [EMAIL PROTECTED] University of Utah CS Department http://www.angio.net/ "If you haul a geek up a crack, you will bloody their fingers for a day... If you teach a geek to climb, you will bloody their fingers for life." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: tee option on ipfw?
Jaye Mathisen writes: The man page says the tee option on ipfw is not yet supported. I'm wondering if that is still the case as of 3.2-stable, or if the doc is just out of date. You are correct, it's still not implemented.. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: USFS (User Space File System)
: :Look into the portal filesystem. This is what you want :) : : Brian Fundakowski Feldman _ __ ___ ___ ___ ___ : gr...@freebsd.org _ __ ___ | _ ) __| \ Actually, it isn't quite. All the portal filesystem will allow you to do is pass back a descriptor. It does not allow you to simulate a filesystem. But something similar to what the portal filesystem does would be cool -- maybe a real protocol to pass the VOP requests down to a user process and get responses data. Portal FS did give me a couple of starting points.. It looks interesting. Just for my own clarification... how would this be different than NFS (specifically local NFS)? -- David Cross | email: cro...@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: USFS (User Space File System)
: :Portal FS did give me a couple of starting points.. It looks interesting. :Just for my own clarification... how would this be different than NFS :(specifically local NFS)? : :-- :David Cross | email: cro...@cs.rpi.edu :Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd NFS isn't a fun protocol to implement. I'd implement a user-level filesystem interface protocol like this: * Have a device similar to portal that a user process can open for the server interface. * Have the ability to mount the 'client side' of the device once the 'server side' has been opened by the user process. * VOP Requests through the mount point are routed to the user process and responses returned. * Device driver handles auto termination of any pending commands if the user process close()'s the server side interface. * User process uses read() and write() to read request structures and write back response structures. (Thus the user process can use select() if it wishes). The request structure can contain a data pointer length. If the device is passing a read or write request to the user level server, it mmap's the data block into the server's address space prior to queueing the command and unmaps it after receiving the response. It would be really cool if someone were to write something like this. I don't think it would be terribly difficult except for the mmap() piece. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: softupdates on root partition, no floppy
On Saturday, 17th July 1999, Matthew Dillon wrote: :Is there any way to force softupdate on on a mounted system, or do I have to :either move the / to another machine, or move a floppydrive to this machine? If you boot single-user, root will be mounted read-only and you should be able to 'tunefs -n enable /dev/rda0a' and reboot. I gave up using soft updates on root because of the delayed delete behaviour. I kept filling up root while updating kernels. It doesn't gain you much on little used file systems anyway. So, I recommend people leave root alone. Stephen. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
At 11:40 AM 18/07/99 -0700, you wrote: Tim Baird wrote: I hope everyone is benefitting by these simple facts *chuckle* Simple facts.. You sound like my physics professor. I for one am benefitting very much from the discussion. I got hired at my current job as a software person, but I have a background in hardware so I try and make it into the NOC every excuse I get (promotability, don't you know). It always helps if sound like I have a vague idea what I'm talking about. :) I'll take that as a compliment ;) I just made up my first ethernet cables the other day, and learned an interesting tidbit that I'm sure is beyond elementary to most of you, but may benefit someone else. What I was told is that the reason Cat 5 cable is so much more efficient is that each of the 4 pairs of wire is twisted at a different rate. This helps reduce the possibility of frequency synchronization for the EM fields the pairs create. Your description (what you were told) here is incorrectthe number of twists in a cable had **NO** effect on the spectral content of the cunducted signal or resulting radiated/induced signal.to do so would require the conductors to have a nonlinear conduction characteristic which they most assuredly do not (for all practical purposes). The design of the cable is such that adjacent pairs have as little effectively parallel length as possible. Obviously, the currents in the wires share the same axis, so the magnetic coupling is only reduced by the fact that interfering magnetic fields will tend to induce a common mode current in adjacent pairs...particulary since both conductors in the receiving cable pair --on average-- are exposed equally, the idea in randomizing the twists is to reduce the capacitive coupling as much as possible. Capacitive coupling is a more localized effect, and thrives when conductors share a common plane in close proximity...this is why capacitors are designed as two metal plates very close together..the electric field between the plates (conductors) is much higher than if they were perpendicular...or not nicely parallel. I hope this clarifies the situation :) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: glibc
On Sun, 18 Jul 1999, Alex Zepeda wrote: Perhaps if you explain what it is you're trying to accomplish, there might be an easier option than porting *shudder* glibc? I need a libc 100% compatible with glibc to make porting (from Linux) easier. And, as a side note, I think both FreeBSD and Linux would benefit of having compatible libc:s. Perhaps porting BSD libc to Linux would be easier? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: glibc
On Mon, 19 Jul 1999, Per Lundberg wrote: I need a libc 100% compatible with glibc to make porting (from Linux) easier. And, as a side note, I think both FreeBSD and Linux would benefit of having compatible libc:s. I seriously doubt this will make porting any easier. 99% of the porting issues you'll run into, are from a.) lack of sys/types.h being included, or order of headers being included. b.) dependencies on Linux-specific ioctls or syscalls, such as clone, which are not really libc related. c.) dependencies on bugs in glibc. Perhaps porting BSD libc to Linux would be easier? I doubt it. The glibc has been designed with portability in mind (hell, it's purported to run on Irix), FreeBSD's with security and speed. - alex What I am is what I am, What you are is what you are - Edie Brickell (ain't she profound?) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
On Sun, 18 Jul 1999 sth...@nethelp.no wrote: Please read the documentation. This is hard since the actual machines and switches are almost 6000 miles away from me and the last time I checked, it didn't come with manuals. I know my way around the Cisco routers but the switches is still a mystery... All of the Cisco documentation is available on WWW. Use it! I known it is but I was talking about the printed copy... Start at http://www.cisco.com/, follow the Technical documents and then the Documentation home page link. The manual for your switch is available, that's where I found the show mac-address-table command. Atleast the Cisco documentation is good... The Ascend documentation sucks big time since none of the stuff in the manual matches the actual OS on the system. Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Determining the return address
Wes Peters w...@softweyr.com writes: On the SPARC, FWIW, the return address is in %i7. What is difficult to determine (programmatically) is if the function is a normal or leaf function; different return sequences are used for each. It doesn't matter; all I need it for is to find the caller's name using dladdr(). DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Determining the return address
Alfred Perlstein bri...@rush.net writes: On 18 Jul 1999, Dag-Erling Smorgrav wrote: Hmm, I ended up using a global variable which I increment at the beginning of the signal handler, and decrement at the end. As long as you make sure the code won't have multiple access that would work. Signal handlers having multiple accesses? When did you last see that happen? DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: glibc
On Mon, 19 Jul 1999, Alex Zepeda wrote: I seriously doubt this will make porting any easier. You think so? I experience a lot of this when I try to recompile stuff for FreeBSD (most of it are due to lack of a real getopt routine). c.) dependencies on bugs in glibc. What bugs have you found in glibc 2.1.1? Have you reported those to the GNU folks? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: glibc
On Mon, 19 Jul 1999, Per Lundberg wrote: You think so? Yes. I experience a lot of this when I try to recompile stuff for FreeBSD (most of it are due to lack of a real getopt routine). *sigh* It's quite easily argued that depending on a *NON STANDARD* getopt routine is a bug. AFAIK *ONLY* glibc has the long-getopt crap, and if that's the only thing you're running into, it should be easy enough to rip out the long getopt code, and add a few proper defines and have the standard libc coexist peacefully with the GNU getopt. c.) dependencies on bugs in glibc. What bugs have you found in glibc 2.1.1? Have you reported those to the GNU folks? I personally haven't found any, but I've seen for instance, kcalc is riddled with ifdefs and warnings about floating point precision stuff and RH 5.something due to glibc bug(s). - alex I thought felt your touch In my car, on my clutch But I guess it's just someone who felt a lot like I remember you. - Translator To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
On Sun, 18 Jul 1999, Jonathan M. Bresler wrote: I guess I forgot about the overhead. I've tested between two FreeBSD machines using Intel Pro100+ NIC cards connected to a Cisco 2924XL Switch Full Duplex and never seen anything close to the speeds. using netperfv2pl3 and FreeBSD 2.2.8 on 300MHz PII with fxp cards (all from memory), i routinely get TCP_STREAM to pushd 94Mbps. i use these machines for stressing every else we have at work. Hmmm, has anyone tried a full duplex test before? Since it seems like the bottleneck is really the speed of the disks.. Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
How much memory do we need to install?
AFAIK, the minimum memory for installation is still 5 MB, and the problems people had with 8MB machines failing to install was a bug, right? What's the current status? Greg - Forwarded message from Thierry Herbelot thierry.herbe...@alcatel.fr - Delivered-To: freebsd-questi...@freebsd.org Date: Mon, 19 Jul 1999 09:49:01 +0200 Reply-To: thierry.herbe...@alcatel.fr Organization: ALCATEL CIT Nanterre X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en To: Ben Salem b...@kscable.com Cc: freebsd-questi...@freebsd.org X-Loop: FreeBSD.ORG Precedence: bulk You must have more than 8 Megs to install FreeBSD TfH Ben Salem wrote: Im attempting to install FreeBSD 3.2-RELEASE on a 486 8mb ram. Everything goes ok until the installation actually begins, it gets to chunk 1 of 106 then stops. The install seems to work fine on my other machines. I have replaced the NIC card, so I think I can rule that out. Any ideas? Thanks Ben Salem - End forwarded message - -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
Hi ... We have previously done many network performance tests for our products running on FreeBSD ... We have found that when ever there is disk accessing involved, it is not a good idea to look at the transfer figures. We did tests with ftp and is was slow (compared to only memory generated data e.g. ttcp) 1. If you want to test the network speed ... use ttcp or something that generates the data and doesn't read it from disk. 2. When doing full-duplex and using fxp cards, stay away from X-over cables ... use a full-duplex switch etc. ... the fxp cards are not made to work with X-over cables (as far as I know - ala Intel spec) note ... only for full-duplex tests. We have done tests in full-duplex with non Intel cards (because we did not have a switch at that time :)) and with max size packets we got around 188.00 Mbps using the de0 driver. Cheers Reinier On Sun, 18 Jul 1999, Jonathan M. Bresler wrote: I guess I forgot about the overhead. I've tested between two FreeBSD machines using Intel Pro100+ NIC cards connected to a Cisco 2924XL Switch Full Duplex and never seen anything close to the speeds. using netperfv2pl3 and FreeBSD 2.2.8 on 300MHz PII with fxp cards (all from memory), i routinely get TCP_STREAM to pushd 94Mbps. i use these machines for stressing every else we have at work. Hmmm, has anyone tried a full duplex test before? Since it seems like the bottleneck is really the speed of the disks.. Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poor ethernet performance?
On Mon, 19 Jul 1999, Reinier Bezuidenhout wrote: Hi ... We have previously done many network performance tests for our products running on FreeBSD ... We have found that when ever there is disk accessing involved, it is not a good idea to look at the transfer figures. We did tests with ftp and is was slow (compared to only memory generated data e.g. ttcp) yeah, I guess all tests should be done without requiring the use of the disk. 1. If you want to test the network speed ... use ttcp or something that generates the data and doesn't read it from disk. ttcp works. The only problem is when I tried it in both directions, at once. the total becomes 11.xMbytes/sec total as opposed to 9.4Mbytes/sec when doing it in one direction only. 2. When doing full-duplex and using fxp cards, stay away from X-over cables ... use a full-duplex switch etc. ... the fxp cards are not made to work with X-over cables (as far as I know - ala Intel spec) note ... only for full-duplex tests. Does anyone actually use X-over cables for 100Mbps Full Duplex since 3Com said CrossOver cables are not rated for 100Mbps or something even though it's Cat5. Actually, in the older Intel docs for the Pro100B, it does say to connect using X-over cable to the switch. We have done tests in full-duplex with non Intel cards (because we did not have a switch at that time :)) and with max size packets we got around 188.00 Mbps using the de0 driver. Pretty interesting. How did you do the full duplex tests? Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] On Sun, 18 Jul 1999, Jonathan M. Bresler wrote: I guess I forgot about the overhead. I've tested between two FreeBSD machines using Intel Pro100+ NIC cards connected to a Cisco 2924XL Switch Full Duplex and never seen anything close to the speeds. using netperfv2pl3 and FreeBSD 2.2.8 on 300MHz PII with fxp cards (all from memory), i routinely get TCP_STREAM to pushd 94Mbps. i use these machines for stressing every else we have at work. Hmmm, has anyone tried a full duplex test before? Since it seems like the bottleneck is really the speed of the disks.. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Buildworld failing from 3.1 to 3-2.stable...
I have a box running 3.1-stable that I wanted to update. sups fine, but the build dies in login with: === usr.bin/login cc -O -pipe -static -Wall -DLOGIN_ACCESS -DLOGALL -I/usr/obj/n/FreeBSD/RELENG_3/src/tmp/usr/include -c /n/FreeBSD/RELENG_3 /src/usr.bin/login/login.c /n/FreeBSD/RELENG_3/src/usr.bin/login/login.c: In function `main': /n/FreeBSD/RELENG_3/src/usr.bin/login/login.c:129: warning: argument `argv' might be clobbered by `longjmp' or `vfork' cc -O -pipe -static -Wall -DLOGIN_ACCESS -DLOGALL -I/usr/obj/n/FreeBSD/RELENG_3/src/tmp/usr/include -c /n/FreeBSD/RELENG_3 /src/usr.bin/login/login_access.c cc -O -pipe -static -Wall -DLOGIN_ACCESS -DLOGALL -I/usr/obj/n/FreeBSD/RELENG_3/src/tmp/usr/include -c /n/FreeBSD/RELENG_3 /src/usr.bin/login/login_fbtab.c cc -O -pipe -static -Wall -DLOGIN_ACCESS -DLOGALL -I/usr/obj/n/FreeBSD/RELENG_3/src/tmp/usr/include -o login login.o logi n_access.o login_fbtab.o -lutil -lcrypt -lpam /usr/obj/n/FreeBSD/RELENG_3/src/tmp/usr/lib/libpam.a(pam_static_modules.o): In function `_pam_get_static_sym': pam_static_modules.o(.text+0x179): undefined reference to `skeyaccess' pam_static_modules.o(.text+0x275): undefined reference to `rad_create_request' pam_static_modules.o(.text+0x283): undefined reference to `rad_strerror' pam_static_modules.o(.text+0x29d): undefined reference to `rad_put_string' pam_static_modules.o(.text+0x2b2): undefined reference to `rad_put_string' pam_static_modules.o(.text+0x2dc): undefined reference to `rad_put_string' pam_static_modules.o(.text+0x2ea): undefined reference to `rad_strerror' pam_static_modules.o(.text+0x308): undefined reference to `rad_put_attr' pam_static_modules.o(.text+0x316): undefined reference to `rad_strerror' pam_static_modules.o(.text+0x32a): undefined reference to `rad_put_int' pam_static_modules.o(.text+0x33e): undefined reference to `rad_strerror' stdin What am I missing here? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
2nd draft: README.serial for handbook
The second draft of the serial console section in the FreeBSD handbook is ready. It is available at the same URL as below. Please review and correct any technical, grammatical, or whatever errors. Thank you. Kazu From time to time people ask questions about the serial console. As README.serial is buried deep inside the kernel source tree, it's almost time to have a decent text on the serial console in our handbook. I am reformatting README.serial so that it can be included in our handbook, and adding bits and pieces to clarify things. I haven't finished it yet, but would like to have your comments now, so that we can make it more informative and useful. I put up the HTML version in: http://www.freebsd.org/~yokota/serialconsole.html and the SGML version in: http://www.freebsd.org/~yokota/serial-console.sgml Please have a look and send me comments, corrections, additional useful text, relevant pointers, etc. Some notes: - The text describes FreeBSD versions 3.0 and 3.1 or later. Version 3.0 doesn't have our new boot loader, so there is a note in the introduction section about it. - Because there are many differences regarding the serial console setup between 2.X systems and 3.X systems, I don't directly deal with 2.X systems in this text. - I am not a SGML expart ;- formatting and links may be wrong. - Some sections are not yet finished :-) - The chapter number is arbitrary. When this text will be eventually included in the handbook, I expect Nik will put it somewhere suitable and give appropriate chapter number. Thank you. Kazu PS: I don't subscribe to the doc ML. Please send mail to the hackers ML or to me directly. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
