Re: LDAP integration
On Tue, 09 Jan 2007 09:22:31 +0200
Danny Braniss <[EMAIL PROTECTED]> 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.
> >
> > 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.
> >
> > 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.
>
> i realy don't know what this has to do with LDAP, but in our
> diskless environment, /etc/rc.initdiskless, has some coded added
> that based on info from DHCP will build a 'personalized' rc.conf
> (the DHCP info is loaded into kenv by boot).
Cool. I will look into that a bit more. Thanks for the heads up on
that.
> ...
> confpath=`kenv conf-path`
> if [ -n "$confpath" ] ; then
> if [ "`expr $confpath : '\(.*\):'`" ] ; then
> echo Mounting $confpath on /conf
> mount_nfs $confpath /conf
> chkerr $? "mount_nfs $confpath /conf"
> to_umount="${to_umount} $confpath"
> fi
> fi
> ...
> eval `kenv | sed -n 's/^rc\.//p'`
> rm -f /etc/rc.conf /etc/rc.conf.local
> for fc in $conf0 $conf1 $conf2 $conf3 $conf4 $conf5 $conf6 $conf7
> $conf8 $conf9 rc.conf.$hostname
> do
> ho=`expr $fc : '\(.*\):'`
> fl=`expr $fc : '.*/\(.*\)'`
> if [ "${ho}" != "" ]; then
> mp=`expr $fc : '\(.*\)/.*'`
> mount_nfs $mp /mnt > /dev/null 2>&1
> if [ -f /mnt/$fl ]; then
> echo "# from $fc /mnt/$fl" >> /etc/rc.conf
> cat /mnt/$fl >> /etc/rc.conf
> fi
> umount /mnt > /dev/null 2>&1
> elif [ -e /conf/$fc ] ; then
> echo "# from /conf/$fc" >> /etc/rc.conf
> cat /conf/$fc >> /etc/rc.conf
> fi
> done
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
iSCSI disconnects dilema
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? danny ___ 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 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.
>
> 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.
>
> 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.
i realy don't know what this has to do with LDAP, but in our diskless
environment, /etc/rc.initdiskless, has some coded added that
based on info from DHCP will build a 'personalized' rc.conf
(the DHCP info is loaded into kenv by boot).
...
confpath=`kenv conf-path`
if [ -n "$confpath" ] ; then
if [ "`expr $confpath : '\(.*\):'`" ] ; then
echo Mounting $confpath on /conf
mount_nfs $confpath /conf
chkerr $? "mount_nfs $confpath /conf"
to_umount="${to_umount} $confpath"
fi
fi
...
eval `kenv | sed -n 's/^rc\.//p'`
rm -f /etc/rc.conf /etc/rc.conf.local
for fc in $conf0 $conf1 $conf2 $conf3 $conf4 $conf5 $conf6 $conf7 $conf8
$conf9 rc.conf.$hostname
do
ho=`expr $fc : '\(.*\):'`
fl=`expr $fc : '.*/\(.*\)'`
if [ "${ho}" != "" ]; then
mp=`expr $fc : '\(.*\)/.*'`
mount_nfs $mp /mnt > /dev/null 2>&1
if [ -f /mnt/$fl ]; then
echo "# from $fc /mnt/$fl" >> /etc/rc.conf
cat /mnt/$fl >> /etc/rc.conf
fi
umount /mnt > /dev/null 2>&1
elif [ -e /conf/$fc ] ; then
echo "# from /conf/$fc" >> /etc/rc.conf
cat /conf/$fc >> /etc/rc.conf
fi
done
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TCP Checksums in mbufs
Lowell Gilbert wrote: Actually, it is as easy as that. And it's exactly the way this kind of case is usually handled. almost.. you need to account for the fact that our computers are 2-s compliment machines and the checksum is a 1-s compliment checksum I think it's given in one of the RFCs but I think it may also be used in the tcpmss port, or possibly the mss fixup code in ppp. I know I've used it somewhere but forget where :-) RFC 1071, but that doesn't include the code. Just the one-sentence explanation of what to do. [And several more sentences of explanation...] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TCP Checksums in mbufs
On Mon, Jan 08, 2007 at 02:00:14PM -0800, Julian Elischer wrote:
> there is an algorythm to recalculate the tcp/ip
> checksum when you replace a byte. you subtract the old value from the
> csum and add the new one, but not quite a as easy as that.
>
> I think it's given in one of the RFCs but I think it may also
> be used in the tcpmss port, or possibly the mss fixup code in ppp.
> I know I've used it somewhere but forget where :-)
Aha! Would it be this one per chance?
/*-
* The following macro is used to update an
* internet checksum. "acc" is a 32-bit
* accumulation of all the changes to the
* checksum (adding in old 16-bit words and
* subtracting out new words), and "cksum"
* is the checksum value to be updated.
*/
#define ADJUST_CHECKSUM(acc, cksum) { \
acc += cksum; \
if (acc < 0) { \
acc = -acc; \
acc = (acc >> 16) + (acc & 0x); \
acc += acc >> 16; \
cksum = (u_short) ~acc; \
} else { \
acc = (acc >> 16) + (acc & 0x); \
acc += acc >> 16; \
cksum = (u_short) acc; \
} \
}
If so I'll set about using this... once I work out what the 32-bit
accumulation bit is :)
Thanks!
Lee
--
Lee Brotherston - <[EMAIL PROTECTED]>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TCP Checksums in mbufs
Julian Elischer <[EMAIL PROTECTED]> writes: > Lee Brotherston wrote: >> Hi, >> >> I have a bit of code I have written that uses pfil to access network >> traffic as it passes between interfaces on a FreeBSD router. One of >> the functions it performs is some incredibly basic rewrites of certain >> packets (keeping the same length, so no issues about sequence >> numbers), but it does alter the payload. >> >> I just wanted to check what is the "proper" way to be going about >> recalculating the checksums on the packet? I can write a function to >> do this and write this into the packet stored in the mbuf directly, >> however I wasn't sure if there was a more acceptable method such as >> flagging it to be re-checksum'd as it's routed, or to offload the >> computation to the NIC or something? >> >> Any thoughts, suggestions, etc very welcome! >> >> By the way, I'm not subscribed to the list right now, so I'd >> appreciate it if people could CC me on replies. >> >> Many thanks >> >> Lee > > there is an algorythm to recalculate the tcp/ip > checksum when you replace a byte. you subtract the old value from the > csum and add the new one, but not quite a as easy as that. Actually, it is as easy as that. And it's exactly the way this kind of case is usually handled. > I think it's given in one of the RFCs but I think it may also > be used in the tcpmss port, or possibly the mss fixup code in ppp. > I know I've used it somewhere but forget where :-) RFC 1071, but that doesn't include the code. Just the one-sentence explanation of what to do. [And several more sentences of explanation...] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TCP Checksums in mbufs
Julian Elischer <[EMAIL PROTECTED]> writes: > Lee Brotherston wrote: >> Hi, >> >> I have a bit of code I have written that uses pfil to access network >> traffic as it passes between interfaces on a FreeBSD router. One of >> the functions it performs is some incredibly basic rewrites of certain >> packets (keeping the same length, so no issues about sequence >> numbers), but it does alter the payload. >> >> I just wanted to check what is the "proper" way to be going about >> recalculating the checksums on the packet? I can write a function to >> do this and write this into the packet stored in the mbuf directly, >> however I wasn't sure if there was a more acceptable method such as >> flagging it to be re-checksum'd as it's routed, or to offload the >> computation to the NIC or something? >> >> Any thoughts, suggestions, etc very welcome! >> >> By the way, I'm not subscribed to the list right now, so I'd >> appreciate it if people could CC me on replies. >> >> Many thanks >> >> Lee > > there is an algorythm to recalculate the tcp/ip > checksum when you replace a byte. you subtract the old value from the > csum and add the new one, but not quite a as easy as that. Actually, it is as easy as that (once you handle the possible overflow). And it's exactly the way this kind of case is usually handled. > I think it's given in one of the RFCs but I think it may also > be used in the tcpmss port, or possibly the mss fixup code in ppp. > I know I've used it somewhere but forget where :-) RFC 1071, but that doesn't include the code. Just the one-sentence explanation of what to do. [And several more sentences of explanation...] ___ 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 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. 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. 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. ___ 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 Mon, 8 Jan 2007 09:21:21 +0100 VANHULLEBUS Yvan <[EMAIL PROTECTED]> wrote: > On Sun, Jan 07, 2007 at 05:59:35PM -0600, Z.C.B. 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. > > Hi. > > What do you want exactly to "integrate" in LDAP ? Exactly what I said. :) Initially I have been looking at rc.conf. > If you mean using a FreeBSD workstation whith users stored in an > extrenal LDAP, yes, it works correctly, and it is not really more > difficult than with a Linux box... Yeah, I am aware of it and use it myself. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: discrepancy between WV2 and LIBGSF Header files?
Bob wrote: Greetings: Let me preface this by saying that I am not C programmer. I am running on FreeBSD 6.1-RELEASE-p10, and my ports and source trees are up to date. While attempting to compile koffice-1.6.1 I ran into this error: In file included from /usr/local/include/wv2/olestream.h:22, from graphicshandler.cpp:23: The offending code is in the file /usr/local/include/wv2/olestorage.h and reads: #include I have libgsf-1.14.1 installed and it installs gsf.h at: /usr/local/include/libgsf-1/gsf/gsf.h I also have wv2-0.2.3 Installed To fix this error, I edited the file /usr/local/include/wv2/olestorage.h and changed: #include to #include Hi, Assuming that the port uses autotools it probably runs pkg-config to get the proper CFLAGS, so make sure the output from the command below produces the right output. pkg-config --cflags libgsf-1 -- Pawel ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TCP Checksums in mbufs
Lee Brotherston wrote: Hi, I have a bit of code I have written that uses pfil to access network traffic as it passes between interfaces on a FreeBSD router. One of the functions it performs is some incredibly basic rewrites of certain packets (keeping the same length, so no issues about sequence numbers), but it does alter the payload. I just wanted to check what is the "proper" way to be going about recalculating the checksums on the packet? I can write a function to do this and write this into the packet stored in the mbuf directly, however I wasn't sure if there was a more acceptable method such as flagging it to be re-checksum'd as it's routed, or to offload the computation to the NIC or something? Any thoughts, suggestions, etc very welcome! By the way, I'm not subscribed to the list right now, so I'd appreciate it if people could CC me on replies. Many thanks Lee there is an algorythm to recalculate the tcp/ip checksum when you replace a byte. you subtract the old value from the csum and add the new one, but not quite a as easy as that. I think it's given in one of the RFCs but I think it may also be used in the tcpmss port, or possibly the mss fixup code in ppp. I know I've used it somewhere but forget where :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
TCP Checksums in mbufs
Hi, I have a bit of code I have written that uses pfil to access network traffic as it passes between interfaces on a FreeBSD router. One of the functions it performs is some incredibly basic rewrites of certain packets (keeping the same length, so no issues about sequence numbers), but it does alter the payload. I just wanted to check what is the "proper" way to be going about recalculating the checksums on the packet? I can write a function to do this and write this into the packet stored in the mbuf directly, however I wasn't sure if there was a more acceptable method such as flagging it to be re-checksum'd as it's routed, or to offload the computation to the NIC or something? Any thoughts, suggestions, etc very welcome! By the way, I'm not subscribed to the list right now, so I'd appreciate it if people could CC me on replies. Many thanks Lee -- Lee Brotherston - <[EMAIL PROTECTED]> smime.p7s Description: S/MIME cryptographic signature
Re: Init.c, making it chroot
In message: <[EMAIL PROTECTED]> Oliver Fromme <[EMAIL PROTECTED]> writes: : : John Baldwin wrote: : > On Saturday 06 January 2007 14:27, Oliver Fromme wrote: : > > M. Warner Losh wrote: : > > > Also, kenv(KENV_GET, ... is used a lot. Maybe it makes sense to have : > > > a simple kenvget call. Would make a few lines a little shorter if : > > > nothing else. : > > : > > KENV_GET is used three times. Using a wrapper function : > > would save 7 characters per call. I don't think it's : > > really worth it. But if you insist, I can update the : > > patch with such a function. : > : > I think just using kenv() is fine. : : OK, so how do we proceed now? : Should I submit a PR containing the patch? Send me the final patch as an attachment to an email, and I'll make sure it gets committed. Warner : I'm also willing to write a bit of documentation for the : new init_* kenv variables, but I'm not sure where to put : it. The existing init_path variable is documented in : loader(8), so maybe it should go there? Also there should : be sample entries in /boot/defaults/loader.conf, of course, : like this: Both ideas are good. : --- loader.conf.orig Mon Jan 8 20:45:23 2007 : +++ loader.conf Mon Jan 8 20:47:48 2007 : @@ -77,6 +77,9 @@ : #boot_verbose="" # -v: Causes extra debugging information to be printed : #init_path="/sbin/init:/sbin/oinit:/sbin/init.bak:/rescue/init:/stand/sysinstall" : # Sets the list of init candidates : +#init_shell="/bin/sh"# The shell binary used by init(8). : +#init_shript="" # Initial script to run by init(8) before chrooting. : +#init_chroot="" # Directory for init(8) to chroot into. : : : ## : : By the way, I just verified in the CVS repository that the : init.c code is identical in HEAD (1.62) and in RELENG_6 : (1.60.2.2). Therefore the patch should apply cleanly to : both HEAD and RELENG_6. Excellent! I look forward to it. BTW, if you have other patches/PRs, please contact me privately and I'll review/commit them. Warner : 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. : : 'Instead of asking why a piece of software is using "1970s technology," : start asking why software is ignoring 30 years of accumulated wisdom.' : : ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Init.c, making it chroot
John Baldwin wrote: > On Saturday 06 January 2007 14:27, Oliver Fromme wrote: > > M. Warner Losh wrote: > > > Also, kenv(KENV_GET, ... is used a lot. Maybe it makes sense to have > > > a simple kenvget call. Would make a few lines a little shorter if > > > nothing else. > > > > KENV_GET is used three times. Using a wrapper function > > would save 7 characters per call. I don't think it's > > really worth it. But if you insist, I can update the > > patch with such a function. > > I think just using kenv() is fine. OK, so how do we proceed now? Should I submit a PR containing the patch? I'm also willing to write a bit of documentation for the new init_* kenv variables, but I'm not sure where to put it. The existing init_path variable is documented in loader(8), so maybe it should go there? Also there should be sample entries in /boot/defaults/loader.conf, of course, like this: --- loader.conf.origMon Jan 8 20:45:23 2007 +++ loader.conf Mon Jan 8 20:47:48 2007 @@ -77,6 +77,9 @@ #boot_verbose="" # -v: Causes extra debugging information to be printed #init_path="/sbin/init:/sbin/oinit:/sbin/init.bak:/rescue/init:/stand/sysinstall" # Sets the list of init candidates +#init_shell="/bin/sh" # The shell binary used by init(8). +#init_shript=""# Initial script to run by init(8) before chrooting. +#init_chroot=""# Directory for init(8) to chroot into. ## By the way, I just verified in the CVS repository that the init.c code is identical in HEAD (1.62) and in RELENG_6 (1.60.2.2). Therefore the patch should apply cleanly to both HEAD and RELENG_6. 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. 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Fwd: [patch] - random(6)
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 "[EMAIL PROTECTED]"
Slow FreeBSD -> Windows performance with inflight enabled
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. This has been mentioned a few times in the past e.g. http://lists.freebsd.org/pipermail/freebsd-stable/2006-February/022622.html http://lists.freebsd.org/pipermail/freebsd-net/2005-November/008989.html But I cant find any real conclusive results. For reference the connection between the test machines is initially GE on both ends but at one point goes via DSL but is still relatively low latency the trace being: Host Loss% Snt Last Avg Best Wrst StDev 1. x.x.x.x 0.0%120.3 0.3 0.3 0.3 0.0 2. x.x.x.x 0.0%120.4 0.4 0.4 0.4 0.0 3. x.x.x.x 8.3%121.4 1.7 1.3 3.1 0.6 4. x.x.x.x 0.0%115.5 10.1 5.5 21.6 5.9 5. x.x.x.x 0.0%117.6 6.8 6.3 7.6 0.3 6. x.x.x.x 0.0%117.7 7.2 6.7 8.1 0.4 Looking at the before and after traces using wireshark on the windows box there are no notable changes just an increased throughput in exchanges. Possibly of note is that the server in question is running a 200HZ kernel. With the common client being Windows I'd say it would be good to get the default improved either by disabling inflight or changing it so that it better detects this sort of common connection arrangement. Does anyone have any ideas why inflight is causing such poor performance? Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Init.c, making it chroot
On Saturday 06 January 2007 14:27, Oliver Fromme wrote: > M. Warner Losh wrote: > > Also, kenv(KENV_GET, ... is used a lot. Maybe it makes sense to have > > a simple kenvget call. Would make a few lines a little shorter if > > nothing else. > > KENV_GET is used three times. Using a wrapper function > would save 7 characters per call. I don't think it's > really worth it. But if you insist, I can update the > patch with such a function. I think just using kenv() is fine. -- John Baldwin ___ 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 Doug Barton <[EMAIL PROTECTED]> (from Sun, 07 Jan 2007 22:02:30 -0800): 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 had the impression that in general the opinion is that it would be nice to have it in the tree, but that the generic infrastructure should be committed first (the GSoC 2006 nss work without the LDAP part) and then a patch should be presented to let the people have a look at the complete picture. Bye, Alexander. -- It's a poor workman who blames his tools. 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: discrepancy between WV2 and LIBGSF Header files?
Bob, good day! I doubt that this posting should go into the freebsd-hackers, but nevertheless ;)) > While attempting to compile koffice-1.6.1 I ran into this error: > > In file included from /usr/local/include/wv2/olestream.h:22, > from graphicshandler.cpp:23: > > The offending code is in the file /usr/local/include/wv2/olestorage.h > and reads: > #include > > I have libgsf-1.14.1 installed and it installs gsf.h at: > /usr/local/include/libgsf-1/gsf/gsf.h > > I also have wv2-0.2.3 Installed > > To fix this error, I edited the file /usr/local/include/wv2/olestorage.h > and changed: > #include > to > #include Please, undo these changes and try to build your port with command 'CFLAGS=-I/usr/local/include/libgsf-1 make clean install clean'. This should clean your build, point the preprocessor to the right location of the gsf/gsf.h, build your port once again, install it and clean the build area. > Can someone either tell me who to report this to, or go ahead and > report this to the proper maintainer? Perhaps the maintainer of koffice > should add a patch? PRs are welcome: they are made through send-pr utility. The maintainer for the port can be looked up using the following command: $ grep MAINTAINER /usr/ports/editors/koffice-kde3/Makefile MAINTAINER= [EMAIL PROTECTED] You can Cc your problem report to him. And if 'CFLAGS' trick will do the work, you can mention it in the report. But previous to sending the PR, look into the PR database: maybe your bug is already reported, but was not handled yet. See http://www.freebsd.org/send-pr.html for the long explanation and links. -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
discrepancy between WV2 and LIBGSF Header files?
Greetings: Let me preface this by saying that I am not C programmer. I am running on FreeBSD 6.1-RELEASE-p10, and my ports and source trees are up to date. While attempting to compile koffice-1.6.1 I ran into this error: In file included from /usr/local/include/wv2/olestream.h:22, from graphicshandler.cpp:23: The offending code is in the file /usr/local/include/wv2/olestorage.h and reads: #include I have libgsf-1.14.1 installed and it installs gsf.h at: /usr/local/include/libgsf-1/gsf/gsf.h I also have wv2-0.2.3 Installed To fix this error, I edited the file /usr/local/include/wv2/olestorage.h and changed: #include to #include This fixed the error. There seems to be a discrepancy between WV2 and LIBGSF as to the proper location of gsf.h Either that, or my installation is not correct. Can someone either tell me who to report this to, or go ahead and report this to the proper maintainer? Perhaps the maintainer of koffice should add a patch? What is strange, and bothers me is that koffice 1.6.1 has been released for a while now, and nobody has run into this? Surely I am not the first to build koffice from sources. Best Regards Bob ___ 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 Mon, 8 Jan 2007, Dave Horsfall wrote: > Out of all the O'Reilly books I have, the LDAP one was the most useless. I forgot to say, "and out of all the LDAP books I have *as well*". -- Dave ___ 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 Mon, 8 Jan 2007, Tom Judge wrote: > I would recommend the "LDAP System Administration" book published by > O'Reilly. I wouldn't, unless a recipe book is your style; there are better books (which will have to wait until I get into work tomorrow). Out of all the O'Reilly books I have, the LDAP one was the most useless. -- Dave ___ 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
VANHULLEBUS Yvan wrote: On Sun, Jan 07, 2007 at 05:59:35PM -0600, Z.C.B. 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. Hi. What do you want exactly to "integrate" in LDAP ? If you mean using a FreeBSD workstation whith users stored in an extrenal LDAP, yes, it works correctly, and it is not really more difficult than with a Linux box... I would recommend the "LDAP System Administration" book published by O'Reilly. Our LDAP directory currently controls most of the core system for both FreeBSD and Linux Systems (Users/Groups, Mail Delivery/Routing, Sudo access rights, SSH Public keys). Tom ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dump reads more than restore writes?
On 1/8/07, Oliver Fromme <[EMAIL PROTECTED]> wrote: However, I think that there must be a bug in gstat when it displays 600 GB read to copy a 200 GB file system. dump(8) is inefficient, but not _that_ inefficient. When doing the dump|restore dance to copy filesystems, I make it a habit to have iostat(1) running. It is _always_ displaying a read rate twice as high as the write rate. And since the iostat/gstat numbers usually match up, eg., dd(1) numbers, I heavily doubt that it's a reporting/statistics glitch. It has to be dump(8). Uli ___ 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 Sun, Jan 07, 2007 at 05:59:35PM -0600, Z.C.B. 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. Hi. What do you want exactly to "integrate" in LDAP ? If you mean using a FreeBSD workstation whith users stored in an extrenal LDAP, yes, it works correctly, and it is not really more difficult than with a Linux box... Yvan. -- NETASQ http://www.netasq.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dump reads more than restore writes?
[EMAIL PROTECTED] wrote: > [...] > > Is dump reading substantially more than restore is writing? > > Quite possibly, esp. if the source disk is nowhere near full and/or > most of the files being handled are small. dump reads every inode > on the disk, including those which are unallocated, I don't think it does that. Why should it read inodes that are unallocated? It reads the directory tree of the file system, so it knows which inodes are allocated, and there's no reason to read anything beyond that. However, it is true that dump|restore is a slow way to copy a file system. It's much faster to mount it and then use something like "cd $SRC; find -d . | cpio -dump $DST", or cpdup (from ports/sysutils/cpdup), or even tar. If the file systems are the same size and nearly full, then dd(1) is probably the fastest way to copy it (but neither of them must be mounted, of course). If it's not nearly full, dd is inefficient because it simply copies the device without regard to what areas are actually unallocated to files. However, I think that there must be a bug in gstat when it displays 600 GB read to copy a 200 GB file system. dump(8) is inefficient, but not _that_ inefficient. 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. "anyone new to programming should be kept as far from C++ as possible; actually showing the stuff should be considered a criminal offence" -- Jacek Generowicz ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
