Re: LDAP integration
On Monday 08 January 2007 11:36, Vulpes Velox wrote: I was just wondering. How many people here have given lots of though about integrating FreeBSD configuration with LDAP. I've just begun looking at it a lot more and was curious as to what other people think in this area. I use OpenLDAP with smbldap-tools to do shared auth between FreeBSD and Windows. I was going to write up a nice tute about it but it got eaten when my laptop HD crashed and I haven't had the enthusiasm to redo it :( It wasn't *too* hard but not exactly trivial either :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpXWQ9G1OGe8.pgp Description: PGP signature
Reserving large contiguous block of RAM for device
Hi, I am in the process of porting a Linux device driver to FreeBSD. In Linux, a large block of RAM (256MB) is reserved by using the 'mem=' and 'memmap=' arguments to the kernel. In the device driver, ioremap() is used to map this memory into kernel virtual memory. In FreeBSD contigmalloc() is available but due to the large amount of physical memory required this may not work reliably. Is there an existing method to reserve a large block of RAM early in the boot process? regards, jacques ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LDAP integration
Quoting Vulpes Velox [EMAIL PROTECTED] (from Mon, 8 Jan 2007 18:52:47 -0600): On Sun, 07 Jan 2007 22:02:30 -0800 Doug Barton [EMAIL PROTECTED] wrote: Vulpes Velox wrote: I was just wondering. How many people here have given lots of though about integrating FreeBSD configuration with LDAP. I've just begun looking at it a lot more and was curious as to what other people think in this area. It would be more useful to have this discussion if you defined what you meant by FreeBSD configuration in more detail. You might also want to search the archives first, there is a lot of discussion about various proposals in this area, all of which end up getting shot down because they don't offer sufficient added value to justify the pain of the change. I mean exactly that. Initially I have begun looking at rc.conf as a logical starting point. It seems I did misunderstand you initially. I thought you where talking about integrating LDAP into the base to allow NSS/PAM stuff to be provided via LDAP. I am currently wondering if any one else working on this, before I start digging to much into it. The only LDAP stuff I am finding on this list has been recently in regards to integration of a ldap nss module into the base system. Right, this is the only major discussion we had in the last months in the public lists. And as long as we (FreeBSD) don't have this, we don't even need to think about getting an rc.conf out of LDAP (we wouldn't be self-hosting anymore if we do this before we have LDAP stuff in the base). Bye, Alexander. -- Far duller than a serpent's tooth it is to spend a quiet youth. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Slow FreeBSD - Windows performance with inflight enabled
On Mon, January 8, 2007 2:58 pm, Steven Hartland wrote: I've just been looking at an issue reported by some of our users that downloads from our one of our sites run on FreeBSD 6.1 and Apache 1.3 where strangely slow. After doing some digging around I found that two remote machines on the same network had wildly different results. The difference being one was Windows (slow) and one was FreeBSD 6.1 (fast). The results where 380Kb/s download speeds on Windows vs 500Kb/s on FreeBSD. I played around and Googled to find that this appears to caused by inflight. Disabling it and restarting apache cures the problem. AFAIK there was some work done on this to make it more adaptive for LAN networks, but im not sure which version got this. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iSCSI disconnects dilema
On Tuesday 09 January 2007 02:06, Danny Braniss wrote: Hi, While I think I have almost solved the problem of network disconnects, It downed on me a major problem: When a 'local' disk crashes, the kernel will probably hang/panic/crash. if i don't try to recover, then there is no change in the above scenario. if i try to recover, then the client does not know that it should umount/fsck/mount. While all this seems familiar, removing a floppy/disk-on-key while it's mounted, we could always say you shouldn't have done that!, with a network connection, it can happen very often - rebooting the target, a network hickup, etc. So, any ideas? I think that an iSCSI network disconnect (if handled properly) is more like a bad/flakey set of sectors and/or extremely high latency than a total disk crash. The initiator should stall as long as it can while trying to reconnect the session, and then send hardware timeout errors up the stack. The the rest of the OS should handle those the same as it would any other timeout errors--retry a certain number of times and then fail. I don't know how graceful the failure case is (perhaps not very), but it's an honest approximation. The above approach is IMO more than adequate for network interruptions lasting a few seconds (or a bit more). I'm not sure there's anything you can realistically do more than that. Administrators who intentionally reboot a nonredundant iSCSI target while it has active sessions are asking for trouble, and if the reboot is accidental they should do one or more of a) know to run fsck manually, b) get a better UPS, c) get a more stable/redundant iSCSI target device. Disclaimer: I know next to nothing about kernel programming, device driver development, or scsi in general. I've just been playing with and thinking about iSCSI on FreeBSD a fair amount lately. Thanks for your continued work on this. JN ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LDAP integration
- Original Message - From: Alexander Leidinger [EMAIL PROTECTED] To: Vulpes Velox [EMAIL PROTECTED] Cc: freebsd-hackers@freebsd.org; Doug Barton [EMAIL PROTECTED] Sent: Tuesday, January 09, 2007 10:19 AM Subject: Re: LDAP integration Quoting Vulpes Velox [EMAIL PROTECTED] (from Mon, 8 Jan 2007 18:52:47 -0600): On Sun, 07 Jan 2007 22:02:30 -0800 Doug Barton [EMAIL PROTECTED] wrote: Vulpes Velox wrote: I was just wondering. How many people here have given lots of though about integrating FreeBSD configuration with LDAP. I've just begun looking at it a lot more and was curious as to what other people think in this area. I''ve been using LDAP a year and a half already: OpenLDAP master OpenLDAP slave TLS supposed of course system users' logins (pam_ldap, nss_ldap) samba (integration with windowz/domain controlling) squid authentication (squid_ldap_auth) apache authentication (modauthldap_apache2) native apache's module is incredibly raw :( vpopmail authentication (I had to write a patch to make vpop work correctly with openldap, but it wasn't accepted in vpopmail community and I dropped it, and now using it only in the house's projects) am going to do qmail with ldap (qmail cluster I mean) a nice management tool phpLDAPadmin helps a lot to manage the DB tree... actually it's been said above: the LDAP play is not trivial and LDAP doesn't give up to a high hand. much reading and experimenting is supposed, - but the output is worthy of it. a year an a half of smooth work and flexibility. I want to describe it step by step and publish, even have some drafts of the future documentation (actually they are scripts with the comments and configuration files), anyway one must learn LDAP very hard to be understanding it very cleary, because any documentation won't help if you're just going to take LDAP with a high hand... -- Making it complicated is easy, making it SIMPLE is an art ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iSCSI disconnects dilema
Danny Braniss wrote: While I think I have almost solved the problem of network disconnects, It downed on me a major problem: When a 'local' disk crashes, the kernel will probably hang/panic/crash. if i don't try to recover, then there is no change in the above scenario. if i try to recover, then the client does not know that it should umount/fsck/mount. While all this seems familiar, removing a floppy/disk-on-key while it's mounted, we could always say you shouldn't have done that!, with a network connection, it can happen very often - rebooting the target, a network hickup, etc. The IEEE1394 code (firewire) contains a hack so you can remove a _mounted_ drive (yes, pull the plug!) and later reconnect it and continue to use the filesystem. I think processes that try to access the file system during the drive being unavailable are blocked (D state a.k.a. diskwait). The purpose of that feature is that you can change the topology (e.g. remove a device that's not at the end of the bus) without having to unmount all other devices. Well, it's just a hack, and I don't know if something similar is applicable to the iSCSI situation. But I thought it wouldn't hurt to mention it anyhow. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor, and when was the last time you needed one? -- Tom Cargil, C++ Journal ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [patch] - random(6)
Probly got stripped of the email somehow, somewhere ;) The patch is attached above... att, victor loureiro lima 2007/1/9, Lucas Holt [EMAIL PROTECTED]: Your patch appeared to get stripped from the mailing list. I would like to try your patch in MidnightBSD which is based on FreeBSD 6 if you'd be willing to email it to me. :) Luke On Jan 8, 2007, at 2:52 PM, Victor Loureiro Lima wrote: I am forwarding this to -hackers, since I havent got any response from the author ([EMAIL PROTECTED]) in months ;/ Maybe someone in here could take a few minutes and check this patch out and maybe commit it to the source tree att, victor loureiro lima -- Forwarded message -- From: Victor Loureiro Lima [EMAIL PROTECTED] Date: 27/11/2006 15:19 Subject: [patch] - random(6) To: [EMAIL PROTECTED] Hello Sean, My name is Victor, I've sent you a patch which solved the bug in which random(6) would be way to slow to handle files that are greater than 10MB+, well, I am re-sending you that same patch with little modifications, do you think you could include it in the src tree? This patch also increases random(6) performance dramatically even when working with small-to-medium file sizes, it should be a good addition to the random(6) source tree, and its also been extensivelly tested against all features of random(6) and it scale really well with big files, for example: -- [EMAIL PROTECTED] yes | head -20 test [EMAIL PROTECTED] time ./random -f test /dev/null 0.257u 0.015s 0:00.27 96.2% 11+14460k 0+0io 0pf+0w [EMAIL PROTECTED] time random -f test /dev/null 187.366u 0.007s 3:07.39 99.9% 10+12945k 0+0io 0pf+0w -- And this was on a Intel Core Duo 2 1.8ghz with 1GB of RAM, with one process taking less than a second to randomize it all, and the other taking 3 minutes, I think its a good patch to be applied on the source tree. I also took the time to change the man page of random(6) to better describe the changes, basically removed the BUGS sections (since that bug is solved by the patch) and included a new line on the HISTORY section describing my contribution to the program :). Attached are the patches for randomize_fd.c and random.6, also a little description of the changes made in randomize_fd.c is in the readme file. Hope you find that this is patch is commitable, I would appreciate to have contributed to FreeBSD even if its just this little contribution :) ciao, victor loureiro lima ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers- [EMAIL PROTECTED] Lucas Holt [EMAIL PROTECTED] FoolishGames.com (Jewel Fan Site) JustJournal.com (Free blogging) FoolishGames.net (Enemy Territory site) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [patch] - random(6)
Bummer... here is the patch: http://setuid.promisc.org/random_faster.tar.gz att, victor loureiro lima 2007/1/9, Victor Loureiro Lima [EMAIL PROTECTED]: Probly got stripped of the email somehow, somewhere ;) The patch is attached above... att, victor loureiro lima 2007/1/9, Lucas Holt [EMAIL PROTECTED]: Your patch appeared to get stripped from the mailing list. I would like to try your patch in MidnightBSD which is based on FreeBSD 6 if you'd be willing to email it to me. :) Luke On Jan 8, 2007, at 2:52 PM, Victor Loureiro Lima wrote: I am forwarding this to -hackers, since I havent got any response from the author ([EMAIL PROTECTED]) in months ;/ Maybe someone in here could take a few minutes and check this patch out and maybe commit it to the source tree att, victor loureiro lima -- Forwarded message -- From: Victor Loureiro Lima [EMAIL PROTECTED] Date: 27/11/2006 15:19 Subject: [patch] - random(6) To: [EMAIL PROTECTED] Hello Sean, My name is Victor, I've sent you a patch which solved the bug in which random(6) would be way to slow to handle files that are greater than 10MB+, well, I am re-sending you that same patch with little modifications, do you think you could include it in the src tree? This patch also increases random(6) performance dramatically even when working with small-to-medium file sizes, it should be a good addition to the random(6) source tree, and its also been extensivelly tested against all features of random(6) and it scale really well with big files, for example: -- [EMAIL PROTECTED] yes | head -20 test [EMAIL PROTECTED] time ./random -f test /dev/null 0.257u 0.015s 0:00.27 96.2% 11+14460k 0+0io 0pf+0w [EMAIL PROTECTED] time random -f test /dev/null 187.366u 0.007s 3:07.39 99.9% 10+12945k 0+0io 0pf+0w -- And this was on a Intel Core Duo 2 1.8ghz with 1GB of RAM, with one process taking less than a second to randomize it all, and the other taking 3 minutes, I think its a good patch to be applied on the source tree. I also took the time to change the man page of random(6) to better describe the changes, basically removed the BUGS sections (since that bug is solved by the patch) and included a new line on the HISTORY section describing my contribution to the program :). Attached are the patches for randomize_fd.c and random.6, also a little description of the changes made in randomize_fd.c is in the readme file. Hope you find that this is patch is commitable, I would appreciate to have contributed to FreeBSD even if its just this little contribution :) ciao, victor loureiro lima ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers- [EMAIL PROTECTED] Lucas Holt [EMAIL PROTECTED] FoolishGames.com (Jewel Fan Site) JustJournal.com (Free blogging) FoolishGames.net (Enemy Territory site) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iSCSI disconnects dilema
Forwarding a relevant comment from a parallel discussion on -questions. -- Forwarded Message -- Subject: Re: iSCSI Date: Tuesday 09 January 2007 11:35 From: Dan Nelson [EMAIL PROTECTED] To: DAve [EMAIL PROTECTED] Cc: Free BSD Questions list freebsd-questions@freebsd.org In the last episode (Jan 09), DAve said: The developers response, for those who are interested. hi Dave, the initiator for iSCSI will hit stable/current real soon now. that was the good news, now for the down side: what was missing all along was recovery from network disconnects, so while I think I have it almost worked out, I've come across a major flow in the iscsi design: when the targets crashes, and comes back, there is no way to tell the client to run an fsck. This is not a problem if the client is mounting the iscsi partition read only. danny Why should the client need to do an fsck? From its point of view it should just look like the target had the iSCSI equivalent of a bus reset. It should resend any queued requests and continue. On Tuesday 09 January 2007 02:06, Danny Braniss wrote: Hi, While I think I have almost solved the problem of network disconnects, It downed on me a major problem: When a 'local' disk crashes, the kernel will probably hang/panic/crash. if i don't try to recover, then there is no change in the above scenario. if i try to recover, then the client does not know that it should umount/fsck/mount. While all this seems familiar, removing a floppy/disk-on-key while it's mounted, we could always say you shouldn't have done that!, with a network connection, it can happen very often - rebooting the target, a network hickup, etc. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iSCSI disconnects dilema
John Nielsen wrote: I don't know how graceful the failure case is (perhaps not very)... Not at all - removing a mounted USB device panics the kernel. signature.asc Description: OpenPGP digital signature
Re: LDAP integration
Vulpes Velox wrote: On Sun, 07 Jan 2007 22:02:30 -0800 Doug Barton [EMAIL PROTECTED] wrote: Vulpes Velox wrote: I was just wondering. How many people here have given lots of though about integrating FreeBSD configuration with LDAP. I've just begun looking at it a lot more and was curious as to what other people think in this area. It would be more useful to have this discussion if you defined what you meant by FreeBSD configuration in more detail. You might also want to search the archives first, there is a lot of discussion about various proposals in this area, all of which end up getting shot down because they don't offer sufficient added value to justify the pain of the change. I mean exactly that. Initially I have begun looking at rc.conf as a logical starting point. Why do you consider rc.d to be a logical starting point? The issue of nss integration is much more useful, especially given that there is critical mass for support to bring ldap into the base to make this happen. Initially I think seeing a rc.d stuck right in right after NETWORKING would be very interesting to have. Right after NETWORKING is finished, a program is kicked off that updates a rc file that is then included after parsing rc.conf. You've stated what you want to do, but you haven't said why. Please note carefully what I said above. You need to demonstrate SIGNIFICANT added value for this proposal to get any kind of serious consideration. All you've said so far is, this would be neat! I was serious about searching the archives, this ground has been pretty well covered. And yes, in case you're wondering, I _am_ being a bit harsh, but it's for a purpose. Unless you really want to do it anyway, I don't want there to be any confusion down the road when you come back to us with a massive patch you expect to be integrated. Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LDAP integration
On Tue, 09 Jan 2007 13:23:29 -0800 Doug Barton [EMAIL PROTECTED] wrote: Vulpes Velox wrote: On Sun, 07 Jan 2007 22:02:30 -0800 Doug Barton [EMAIL PROTECTED] wrote: Vulpes Velox wrote: I was just wondering. How many people here have given lots of though about integrating FreeBSD configuration with LDAP. I've just begun looking at it a lot more and was curious as to what other people think in this area. It would be more useful to have this discussion if you defined what you meant by FreeBSD configuration in more detail. You might also want to search the archives first, there is a lot of discussion about various proposals in this area, all of which end up getting shot down because they don't offer sufficient added value to justify the pain of the change. I mean exactly that. Initially I have begun looking at rc.conf as a logical starting point. Why do you consider rc.d to be a logical starting point? The issue of nss integration is much more useful, especially given that there is critical mass for support to bring ldap into the base to make this happen. I do want to see it in the base, but what I want is even less intrusive than this. I want to get the infastructure in place for supporting doing this type of thing. I am largely focusing on the idea of LDAP right now, but I see no reason the base part can't be written in a neutral manner that it can non-instrusively be included in the base in little more than a single rc.d for kicking off a program specified in rc.conf to take care of that. This allows the user to easily choose from a system from the ports that fits their need. What I am thinking is a the rc.d file runs the command specified, the program or script prints a list of files it is going to update, those files are then backed up, and the program then installs the new files. Upon not being able to update, it can be leave the files in place, run a specified command, or pull in a set of default files. What do you think? :) Initially I think seeing a rc.d stuck right in right after NETWORKING would be very interesting to have. Right after NETWORKING is finished, a program is kicked off that updates a rc file that is then included after parsing rc.conf. You've stated what you want to do, but you haven't said why. Please note carefully what I said above. You need to demonstrate SIGNIFICANT added value for this proposal to get any kind of serious consideration. All you've said so far is, this would be neat! I was serious about searching the archives, this ground has been pretty well covered. The why is because I like centralized management and it would be really handy for that. For my use, it would be handy in regards to my laptops. I feel better central management is extreme significant. If I had nothing more to say than this would be neat! we would not still be talking. Right now I am just poking around for other people I regards to searching the archives, I am not seeing any thing in regards to LDAP outside of NSS recently. I am also not finding any thing in regards to dynamically and automatically building various config files. And yes, in case you're wondering, I _am_ being a bit harsh, but it's for a purpose. Unless you really want to do it anyway, I don't want there to be any confusion down the road when you come back to us with a massive patch you expect to be integrated. There will be no massive patch for it, given it involves little more than the inclusion of a single rc.d file and a bit of documentation. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
