Re: LDAP integration
Freddie Cash wrote: To each their own, of course. Personally, I am so sick of the way system like Debian use dozens of config files for each app, all in their own conf.d/ sub-directories. Some apps, like PureFTPd actually use separate config files for each and every option it supports. Trying to configure these apps is a royal pain of opening and editing a dozen files. Maybe this makes it easier for automated configuration tools and GUIs, but it makes it a *ROYAL* pain in the arse for mere mortals using text editors to manage. But management of config data is a user interface, surely, and not directly related to the underlying storage mechanism. What is the logical difference between using a directory structure vs. an LDAP server containing essentially the same information (plus all of the overhead)? dozens of config files just equates to dozens of ldap entries (or dozens of entries in a single config file). Given the same or equivalent friendly UI, do you really care how the back end is managed? By moving the data to a directory you are making it less accessible to standard tools, so you're just removing the option to directly edit those config files and only gain on being able to use ldap editing tools instead of text editing tools. You could write a similarly friendly app that managed your conrfiguration files, and you won't need any LDAP expertise to use it. Network access and management of configuration data are the real advantages here, not the UI. Integration of LDAP would provide close to (and arguably less than) zero benefit to a stand alone system, really, and would effectively equate to a Windows registry with all of the pros and cons that come with that. Regards -d ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel hang on 6.x
On Wed, 2007-Jan-10 22:11:38 -0500, John Baldwin wrote: 64 / 14. That gives a result of 153405586. However, you really want to round this up to a multiple of 288 (because the kernel rounds it down to a multiple of 288), so I'd use a value of at least 153405792. Looking at the code, it seems that each SWAPMETA object manages 16 pages. And yes, that means you are setting aside a little over 146 MB of wired, physical RAM just to hold metadata for your swap. :) Given a system with 16GB RAM, this probably isn't a serious issue. -- Peter Jeremy pgpuCmNLuoT1W.pgp Description: PGP signature
Re: LDAP integration
On Thu, 11 Jan 2007 18:41:47 +1100 David Nugent [EMAIL PROTECTED] wrote: Freddie Cash wrote: To each their own, of course. Personally, I am so sick of the way system like Debian use dozens of config files for each app, all in their own conf.d/ sub-directories. Some apps, like PureFTPd actually use separate config files for each and every option it supports. Trying to configure these apps is a royal pain of opening and editing a dozen files. Maybe this makes it easier for automated configuration tools and GUIs, but it makes it a *ROYAL* pain in the arse for mere mortals using text editors to manage. But management of config data is a user interface, surely, and not directly related to the underlying storage mechanism. What is the logical difference between using a directory structure vs. an LDAP server containing essentially the same information (plus all of the overhead)? dozens of config files just equates to dozens of ldap entries (or dozens of entries in a single config file). Given the same or equivalent friendly UI, do you really care how the back end is managed? By moving the data to a directory you are making it less accessible to standard tools, so you're just removing the option to directly edit those config files and only gain on being able to use ldap editing tools instead of text editing tools. You could write a similarly friendly app that managed your conrfiguration files, and you won't need any LDAP expertise to use it. Network access and management of configuration data are the real advantages here, not the UI. Integration of LDAP would provide close to (and arguably less than) zero benefit to a stand alone system, really, and would effectively equate to a Windows registry with all of the pros and cons that come with that. I vote both are completely stupid. LDAP is nice organizing across many systems, but if you are just dealing with one computer it is complete over kill for any thing. Splitting rc.conf up into multiple files is just plain messy and stupid as well. I can see there being times when it is split into two, but I don't see any reason for more than that. There are plenty of nice ways to access and modify LDAP data. I would say it is easily as friendly as editing text files to be pulled across. I fail to see how LDAP is not a standard tool. It is a tool that is really under utilized. What this gains is being able to store a lot of configuration stuff in the same place. It makes permission handling a lot easier as well. If you store it in a file any one with write access can edit it, but with LDAP it can assign write access to specific attributes. With files you would have to split it up across multiple files. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: re(4) incorrect checksum
Pietro Cerutti schreef: Hi lists, FreeBSD gahrtop.localhost 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #1: Tue Jan 9 19:34:13 CET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GAHRTOP i386 CPU: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz (2000.15-MHz 686-class CPU) Cores per package: 2 re0: RealTek 8168B/8111B PCIe Gigabit Ethernet port 0xc800-0xc8ff mem 0xff2ff000-0xff2f irq 17 at device 0.0 on pci2 ($FreeBSD: src/sys/dev/re/if_re.c,v 1.46.2.20 2006/09/21 11:08:28 yongari Exp $) I get checksum errors on every packet I send, example: Checksum: 0x0bc5 [incorrect, should be 0x78fe (maybe caused by checksum offloading?)] I think this could be the cause of some web pages (e.g. Gmail in standard view [html view works well]) not to be displayed. I tracked down the problem to the re(4) driver just because wlan works good... Any ideas? I'm also seeing these www problems with my re(4) card (chipid 0x816810ec), see http://lists.freebsd.org/pipermail/freebsd-current/2006-December/068333.html Wireless is ok. Thanx, Regards, Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) It won't fit on the line. -- me, 2001 ___ 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 Wed, January 10, 2007 2:43 pm, Lamont Granquist wrote:
On Wed, 10 Jan 2007, Doug Barton wrote:
Lamont Granquist wrote:
On Wed, 10 Jan 2007, Doug Barton wrote:
And if you're looking specifically at the /etc/rc.conf config
file, what would be more useful would be an /etc/rc.conf.d/
directory.
Good news for you, we already support that. :) I agree that it
makes a great tool for the many systems problem, and could
reasonably be used for part of the dynamic laptop problem too.
7-current feature? I'm not seeing it in rc.conf(5) on my
RELENG_6-ish
system...
It's not documented, but the code is there in /etc/rc.subr:
grep 'rc.conf\.d' /etc/rc.subr if [ -f /etc/rc.conf.d/$_name ];
then debug Sourcing /etc/rc.conf.d/${_name} .
/etc/rc.conf.d/$_name
...
If i understand that correctly its not *exactly* what i was looking
for, but its better than a monolithic /etc/rc.conf
It looks like you must put /etc/rc.d/inetd config into either
/etc/rc.conf or /etc/rc.config.d/inetd.
That means that if you've got two different orthogonal applications
runing on the same server which both need to run something orthogonal
out of inetd then they still wind up needing to do edits to the same
config file to get inetd configured correctly. I'd rather see
/etc/rc.config.d/app01 and /etc/rc.config.d/app02 both able to tweak
inetd settings. Of
course there is the possibility that app01 and app02 could drop
mutually conflicting inetd setttings, but you've got that problem
anyway in the existing scheme...
To each their own, of course. Personally, I am so sick of the way
system like Debian use dozens of config files for each app, all in
their own conf.d/ sub-directories. Some apps, like PureFTPd actually
use separate config files for each and every option it supports.
Trying to configure these apps is a royal pain of opening and editing
a dozen files. Maybe this makes it easier for automated configuration
tools and GUIs, but it makes it a *ROYAL* pain in the arse for mere
mortals using text editors to manage.
What is wrong with 1 editable text file per app? With a single
sub-directory per application for config files? Where you can
quickly, and easily view all the options at a glance?
The nicest thing about FreeBSD is /etc/rc.conf, a single configuration
file that is easily editable in any text editor. Makes managing
systems remotely so simple.
Freddie Cash, LPIC-2 CCNT CCLPHelpdesk / Network Support Tech.
School District 73(250) 377-HELP [377-4357]
[EMAIL PROTECTED] [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: Kernel hang on 6.x
On Wed, Jan 10, 2007 at 10:11:38PM -0500, John Baldwin wrote: On Wednesday 10 January 2007 19:15, Brad L. Chisholm wrote: I notice the following in the vm.zone output captured just prior to a hang. Does this value correspond to the swap_zone you were referring to? This looks like a limit may have been reached. SWAPMETA:288, 116519, 116519, 0, 116543 yep, that's exactly the issue you are hitting. I don't seem to be able to query kern.maxswzone on our 6.2-BETA2 image: # sysctl kern.maxswzone sysctl: unknown oid 'kern.maxswzone' Is it available in 6.x, or is it something newer? It's only a tunable, not available as a sysctl. You can figure out the current size from the vmstat output above, then do some math to figure out a good guess to use based on how much swap it had in use when it locked up. For example, right now you have 116519 objects of size 288, so 33557472 bytes allocated. You said you die when 14 GB out of 64 total is used, so you should probably try taking that value and multiplying it by 64 / 14. That gives a result of 153405586. However, you really want to round this up to a multiple of 288 (because the kernel rounds it down to a multiple of 288), so I'd use a value of at least 153405792. And yes, that means you are setting aside a little over 146 MB of wired, physical RAM just to hold metadata for your swap. :) Excellent! Increasing kern.maxswzone has indeed fixed the problem. Can this value be auto-tuned better based upon the size of swap, or is it the particular swapping pattern caused by our environment that caused the default size to be insufficient? In any case, the kernel printf you added recently should help make this much easier to diagnose in the future. Thanks for your help! --- Brad Chisholm [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: re(4) incorrect checksum
On Thu, Jan 11, 2007 at 12:14:34PM +0100, Rene Ladan wrote: Pietro Cerutti schreef: Hi lists, FreeBSD gahrtop.localhost 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #1: Tue Jan 9 19:34:13 CET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GAHRTOP i386 CPU: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz (2000.15-MHz 686-class CPU) Cores per package: 2 re0: RealTek 8168B/8111B PCIe Gigabit Ethernet port 0xc800-0xc8ff mem 0xff2ff000-0xff2f irq 17 at device 0.0 on pci2 ($FreeBSD: src/sys/dev/re/if_re.c,v 1.46.2.20 2006/09/21 11:08:28 yongari Exp $) I get checksum errors on every packet I send, example: Checksum: 0x0bc5 [incorrect, should be 0x78fe (maybe caused by checksum offloading?)] I think this could be the cause of some web pages (e.g. Gmail in standard view [html view works well]) not to be displayed. I tracked down the problem to the re(4) driver just because wlan works good... Any ideas? I'm also seeing these www problems with my re(4) card (chipid 0x816810ec), see http://lists.freebsd.org/pipermail/freebsd-current/2006-December/068333.html Does your re(4) also work when you disable checksum offload? Wireless is ok. Thanx, Regards, Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) It won't fit on the line. -- me, 2001 -- Regards, Pyun YongHyeon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Best practices for using gjournal with gmirror?
John Nielsen wrote: 2) When using gjournal and for a gmirror volume, does the journal need to be mirrored as well to maintain redundancy? If so, when storing the journal on Yes, and to maintain consistency. If your machine dies while data is still in journal and not yet committed to permanent storage, you might have corruption. the same physical disks as the mirror, is it better to mirror at the slice level (journal and fs on different partitions in the same mirror) or at the partition level (journal and fs each have their own mirror) or does it matter? It doesn't matter. By default journal will be created inside the same partition as the file system. 4) In the same vein as 3)--does a gjournal volume need to be fsck'ed after a crash? If not, will it just work (e.g. fsck -p sees that the filesystem is clean) or does it need to be disabled somehow? Fsck will still run, but there will be no need for it to check the entire file system, only some summary information and unlinked files. It will be as fast as fsck on softupdates-enabled file system. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel hang on 6.x
On Wed, Jan 10, 2007 at 10:11:38PM -0500, John Baldwin wrote: On Wednesday 10 January 2007 19:15, Brad L. Chisholm wrote: SWAPMETA:288, 116519, 116519, 0, 116543 yep, that's exactly the issue you are hitting. Thanks, John! That's awesome. I agree with Brad that if it is possible to autosize this at boot based on swap size, that would be the thing to do. Thanks very much for your help. -Brian -- Brian Dean [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: Best practices for using gjournal with gmirror?
On Thu, Jan 11, 2007 at 15:30:06 +0100, Ivan Voras wrote: John Nielsen wrote: [...] is it better to mirror at the slice level (journal and fs on different partitions in the same mirror) or at the partition level (journal and fs each have their own mirror) or does it matter? It doesn't matter. By default journal will be created inside the same partition as the file system. It matters a bit - in case of a single mirror (and all partitions on top of it) when there is a crash, during disk activity, the whole mirror will get rebuild. While if there is a separate mirror for each filesystem the chance is that some filesystems will not be active during the power failure/crash and thus their mirror will not need to be rebuild. It is just a matter of speed, not data loss, and it depends on the usage of the filesystems. Currently I have 2 mirrors and after a crash just one of them is rebuild because the other one is rarely used. -- Vasil Dimov [EMAIL PROTECTED] % Shaw's Principle: Build a system that even a fool can use, and only a fool will want to use it. pgprkzevUK6QY.pgp Description: PGP signature
Re: re(4) incorrect checksum
Pyun YongHyeon schreef: On Thu, Jan 11, 2007 at 12:14:34PM +0100, Rene Ladan wrote: Pietro Cerutti schreef: Hi lists, FreeBSD gahrtop.localhost 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #1: Tue Jan 9 19:34:13 CET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GAHRTOP i386 CPU: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz (2000.15-MHz 686-class CPU) Cores per package: 2 re0: RealTek 8168B/8111B PCIe Gigabit Ethernet port 0xc800-0xc8ff mem 0xff2ff000-0xff2f irq 17 at device 0.0 on pci2 ($FreeBSD: src/sys/dev/re/if_re.c,v 1.46.2.20 2006/09/21 11:08:28 yongari Exp $) I get checksum errors on every packet I send, example: Checksum: 0x0bc5 [incorrect, should be 0x78fe (maybe caused by checksum offloading?)] I think this could be the cause of some web pages (e.g. Gmail in standard view [html view works well]) not to be displayed. I tracked down the problem to the re(4) driver just because wlan works good... Any ideas? I'm also seeing these www problems with my re(4) card (chipid 0x816810ec), see http://lists.freebsd.org/pipermail/freebsd-current/2006-December/068333.html Does your re(4) also work when you disable checksum offload? Yes, 'ifconfig re0 -txcsum' does the trick. re0: RealTek 8168/8111B PCIe Gigabit Ethernet port 0xc800-0xc8ff mem 0xfe0ff000-0xfe0f irq 16 at device 0.0 on pci2 if.re.c revision 1.80 2006/12/20 02:13:59 marius Regards, Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) It won't fit on the line. -- me, 2001 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel hang on 6.x
On Thursday 11 January 2007 04:21, Peter Jeremy wrote: On Wed, 2007-Jan-10 22:11:38 -0500, John Baldwin wrote: 64 / 14. That gives a result of 153405586. However, you really want to round this up to a multiple of 288 (because the kernel rounds it down to a multiple of 288), so I'd use a value of at least 153405792. Looking at the code, it seems that each SWAPMETA object manages 16 pages. Up to 16 pages. Not all 16 slots are always used apparently (based on empirical evidence where I've locked up a box that had enough swap_zone items for all of swap space assuming each object mapped 16 pages and it still deadlocked). I think it depends on the access pattern as to how full the various objects are. -- 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: Kernel hang on 6.x
On Thursday 11 January 2007 02:04, Brad L. Chisholm wrote: On Wed, Jan 10, 2007 at 10:11:38PM -0500, John Baldwin wrote: On Wednesday 10 January 2007 19:15, Brad L. Chisholm wrote: I notice the following in the vm.zone output captured just prior to a hang. Does this value correspond to the swap_zone you were referring to? This looks like a limit may have been reached. SWAPMETA:288, 116519, 116519, 0, 116543 yep, that's exactly the issue you are hitting. I don't seem to be able to query kern.maxswzone on our 6.2-BETA2 image: # sysctl kern.maxswzone sysctl: unknown oid 'kern.maxswzone' Is it available in 6.x, or is it something newer? It's only a tunable, not available as a sysctl. You can figure out the current size from the vmstat output above, then do some math to figure out a good guess to use based on how much swap it had in use when it locked up. For example, right now you have 116519 objects of size 288, so 33557472 bytes allocated. You said you die when 14 GB out of 64 total is used, so you should probably try taking that value and multiplying it by 64 / 14. That gives a result of 153405586. However, you really want to round this up to a multiple of 288 (because the kernel rounds it down to a multiple of 288), so I'd use a value of at least 153405792. And yes, that means you are setting aside a little over 146 MB of wired, physical RAM just to hold metadata for your swap. :) Excellent! Increasing kern.maxswzone has indeed fixed the problem. Can this value be auto-tuned better based upon the size of swap, or is it the particular swapping pattern caused by our environment that caused the default size to be insufficient? In any case, the kernel printf you added recently should help make this much easier to diagnose in the future. Thanks for your help! The kernel does do a guess, but it doesn't always get the guess right, and I think there might be a bug where it always guesses wrong for 32GB of swap. :) -- 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
Vulpes Velox wrote: I vote both are completely stupid. LDAP is nice organizing across many systems, but if you are just dealing with one computer it is complete over kill for any thing. Splitting rc.conf up into multiple files is just plain messy and stupid as well. I can see there being times when it is split into two, but I don't see any reason for more than that. This is a UI issue. I personally prefer one file, I don't have to wade though directories searching for any specific knob. :) There are plenty of nice ways to access and modify LDAP data. I would say it is easily as friendly as editing text files to be pulled across. .. and can be scripted in a variety of languages. I fail to see how LDAP is not a standard tool. It is a tool that is really under utilized. Because it is a tool that incurs a cost to learn, configure and deploy. I'm not denying the benefits at all. But I think it must be an option, at least until the advantages gain momentum. What this gains is being able to store a lot of configuration stuff in the same place. It makes permission handling a lot easier as well. If you store it in a file any one with write access can edit it, but with LDAP it can assign write access to specific attributes. With files you would have to split it up across multiple files. Again, there is a cost. You would be adding a third security framework to an ldap enabled system (we already have unix credentials overlaid by the MAC framework to which we add ldap directory rights), and they need to relate in some way since they are dependent when supporting a consistent security profile. LDAP ACLs and understanding issues such as DIT structure, schemas, properties and attributes and how and why of ldap searches doesn't come naturally either, so you're dealing with a non-trivial learning curve. The benefits are plain to the 'already enlightened' but difficult to convince those who are not unless there is a very real problem to solve, not just a desire to deploy the technology for whatever reason. Maybe the technology will eventually become completely robust, easily installed and managed and offer some very significant benefits. I may be wrong, but I don't think we are at that point quite yet, but I'd certainly like to see it happen and probably will at some point in the future. Regards, -d ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Getting a patch commited
I know everyone is busy with getting 6.2 out the door but could someone commit the patch at conf/107453 ? Thanks Josef -- Josef Grosch | Another day closer to a | FreeBSD 6.1 [EMAIL PROTECTED] | Micro$oft free world | Berkeley, Ca. pgp8tqY1WRPsG.pgp Description: PGP signature
Re: LDAP integration
In [EMAIL PROTECTED], Vulpes Velox [EMAIL PROTECTED] typed: LDAP is nice organizing across many systems, but if you are just dealing with one computer it is complete over kill for any thing. In that situation, it's not merely overkill, it's may actually be a bad idea. Can you say AIX SDR? How about Windows registry? Those system both took the approach of putting all the configuration information in a central database. This creates problems because the tools needed to examine/fix the config database require a complex environment - at least compared to a statically linked copy of ed. LDAP may not be so bad, but it still makes me nervous. On the other hand, if you've got a flock of boxes to manage, having a way to tell the rc subsystem Go read config values from this LDAP server seems like a very attractive alternative. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ 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
Mike Meyer wrote: In [EMAIL PROTECTED], Vulpes Velox [EMAIL PROTECTED] typed: LDAP is nice organizing across many systems, but if you are just dealing with one computer it is complete over kill for any thing. In that situation, it's not merely overkill, it's may actually be a bad idea. Can you say AIX SDR? How about Windows registry? Those system both took the approach of putting all the configuration information in a central database. This creates problems because the tools needed to examine/fix the config database require a complex environment - at least compared to a statically linked copy of ed. LDAP may not be so bad, but it still makes me nervous. On the other hand, if you've got a flock of boxes to manage, having a way to tell the rc subsystem Go read config values from this LDAP server seems like a very attractive alternative. And to think, all these years I've been wasting my time and effort using NFS and rsync to centralize the configurations of server farms. -- Darren Pilgrim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Use of /etc/rc.conf.d (Was: Re: LDAP integration)
Lamont Granquist wrote:
On Wed, 10 Jan 2007, Doug Barton wrote:
It's not documented, but the code is there in /etc/rc.subr:
grep 'rc.conf\.d' /etc/rc.subr
if [ -f /etc/rc.conf.d/$_name ]; then
debug Sourcing /etc/rc.conf.d/${_name}
. /etc/rc.conf.d/$_name
...
If i understand that correctly its not *exactly* what i was looking for,
but its better than a monolithic /etc/rc.conf
It looks like you must put /etc/rc.d/inetd config into either
/etc/rc.conf or /etc/rc.config.d/inetd.
Actually you can use both, but where variable names overlap whatever
is sourced last will win.
That means that if you've got two different orthogonal applications
runing on the same server which both need to run something orthogonal
out of inetd then they still wind up needing to do edits to the same
config file to get inetd configured correctly.
Not exactly (and I think you're overusing the term orthogonal). :)
rc.conf and /etc/rc.conf.d only store configuration for the rc.d
scripts themselves. The configuration of inetd is still stored in
/etc/inetd.conf.
$ grep inetd /etc/defaults/rc.conf
inetd_enable=NO # Run the network daemon dispatcher (YES/NO).
inetd_program=/usr/sbin/inetd # path to inetd, if you want a
different one.
inetd_flags=-wW -C 60 # Optional flags to inetd
vs. everything that is in /etc/inetd.conf.
I'd rather see
/etc/rc.config.d/app01 and /etc/rc.config.d/app02 both able to tweak
inetd settings. Of course there is the possibility that app01 and app02
could drop mutually conflicting inetd setttings, but you've got that
problem anyway in the existing scheme...
I think this'd be great, I can't wait to see your patches. :)
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: Use of /etc/rc.conf.d (Was: Re: LDAP integration)
On Thu, 11 Jan 2007, Doug Barton wrote: Lamont Granquist wrote: If i understand that correctly its not *exactly* what i was looking for, but its better than a monolithic /etc/rc.conf It looks like you must put /etc/rc.d/inetd config into either /etc/rc.conf or /etc/rc.config.d/inetd. Actually you can use both, but where variable names overlap whatever is sourced last will win. Yeah, poor english, I didn't mean to imply xor. That means that if you've got two different orthogonal applications runing on the same server which both need to run something orthogonal out of inetd then they still wind up needing to do edits to the same config file to get inetd configured correctly. Not exactly (and I think you're overusing the term orthogonal). :) I think what i really need to do is dig deeper to find truly orthogonal config in /etc/rc.conf. I realized after i posted that i was mixing up inetd settings of /etc/rc.conf and /etc/inetd.conf settings (the latter could really use being busted up int /etc/inetd.d or just using xinetd -- i'm guessing i'll probably find a bikeshed about xinetd if i search the archives though since i can't be the first person to suggest that...) I'd rather see /etc/rc.config.d/app01 and /etc/rc.config.d/app02 both able to tweak inetd settings. Of course there is the possibility that app01 and app02 could drop mutually conflicting inetd setttings, but you've got that problem anyway in the existing scheme... I think this'd be great, I can't wait to see your patches. :) I'll be diving in canada over the three day weekend, so we'll have to see how much i care about this issue a week from now... ___ 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 Thu, 11 Jan 2007, Mike Meyer wrote: In [EMAIL PROTECTED], Vulpes Velox [EMAIL PROTECTED] typed: LDAP is nice organizing across many systems, but if you are just dealing with one computer it is complete over kill for any thing. In that situation, it's not merely overkill, it's may actually be a bad idea. Can you say AIX SDR? How about Windows registry? And then you take the windows registry from 1,000 machines and cram them into a centralized database and try to manage the resultant mess. I don't think this is a good solution. ___ 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 Thu, 11 Jan 2007, Vulpes Velox wrote: I vote both are completely stupid. LDAP is nice organizing across many systems, but if you are just dealing with one computer it is complete over kill for any thing. Splitting rc.conf up into multiple files is just plain messy and stupid as well. I can see there being times when it is split into two, but I don't see any reason for more than that. When was the last time you worked on a configuration management system which maintained 30,000 servers and had ~50 people with commit access to it? In such a situation you wind up with multiple people managing horizontal slices out of all of the machines. You no longer have the model of a single admin for a single server who knows everything about the config of a given machine. In that situation it becomes very useful for admin #1 who is managing a particular aspect of the config to be able to drop a file like /etc/rc.conf.d/foo and admin #2 who is managing a different aspect of the config to be able to drop a file like /etc/rc.conf.d/bar. Having both of them editing /etc/rc.conf opens up the very real possiblity of having simple editing conflicts which corrupt the file. What I'm talking about with splitting up /etc/rc.conf isn't really orthogonal to anything that you've written about LDAP, however. You don't have to attack this idea just to make LDAP sound good. There are plenty of nice ways to access and modify LDAP data. I would say it is easily as friendly as editing text files to be pulled across. I fail to see how LDAP is not a standard tool. It is a tool that is really under utilized. In general database-driven configuration management is under utilized, I'll agree with that. LDAP is the first tool that you're going to pick up to do that, but I think its utility for the generalized problem is not as large as you think it is. What this gains is being able to store a lot of configuration stuff in the same place. It makes permission handling a lot easier as well. If you store it in a file any one with write access can edit it, but with LDAP it can assign write access to specific attributes. With files you would have to split it up across multiple files. I simply don't understand why you want to start picking up raw configuration data on the end host and dumping it into LDAP. That doesn't solve a problem. I don't need host-by-host rc.conf variables or systls exposed through a database interface. I can use labels inside of cfengine to define roles which cause all kinds of actions to be taken, including setting /etc/rc.conf, setting sysctls, pushing scripts, managing daemons, mounting filesystems, etc, etc. What becomes useful is having those labels put into a database, not the results of the config itself. You could try to generate a completely database-driven configuration management language. So that in your schema for a given role you would attatch not only /etc/rc.conf information, but all the sysctls, daemon management, filesystem mounts, etc. But then the scope of what you're doing can be looked at as taking a cfengine configuration file (defining all the given config management steps taken for a given role) and putting it into a database. Without going all the way what you're trying to build isn't going to be very useful and I don't see the driver to do all that work. What is the compelling use case for taking the existing cfengine language (or any other CM language, e.g. puppet) and making it entirely database driven? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: re(4) incorrect checksum
On Thu, Jan 11, 2007 at 04:37:05PM +0100, Rene Ladan wrote: Pyun YongHyeon schreef: On Thu, Jan 11, 2007 at 12:14:34PM +0100, Rene Ladan wrote: Pietro Cerutti schreef: Hi lists, FreeBSD gahrtop.localhost 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #1: Tue Jan 9 19:34:13 CET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GAHRTOP i386 CPU: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz (2000.15-MHz 686-class CPU) Cores per package: 2 re0: RealTek 8168B/8111B PCIe Gigabit Ethernet port 0xc800-0xc8ff mem 0xff2ff000-0xff2f irq 17 at device 0.0 on pci2 ($FreeBSD: src/sys/dev/re/if_re.c,v 1.46.2.20 2006/09/21 11:08:28 yongari Exp $) I get checksum errors on every packet I send, example: Checksum: 0x0bc5 [incorrect, should be 0x78fe (maybe caused by checksum offloading?)] I think this could be the cause of some web pages (e.g. Gmail in standard view [html view works well]) not to be displayed. I tracked down the problem to the re(4) driver just because wlan works good... Any ideas? I'm also seeing these www problems with my re(4) card (chipid 0x816810ec), see http://lists.freebsd.org/pipermail/freebsd-current/2006-December/068333.html Does your re(4) also work when you disable checksum offload? Yes, 'ifconfig re0 -txcsum' does the trick. re0: RealTek 8168/8111B PCIe Gigabit Ethernet port 0xc800-0xc8ff mem 0xfe0ff000-0xfe0f irq 16 at device 0.0 on pci2 if.re.c revision 1.80 2006/12/20 02:13:59 marius Can you confirm that you see checksum errors when viewing the packet from another host on the subnet? It's of course to be expected that a sending host with checksum offload on the NIC will not see the correct checksum before offloading the packet to the NIC, and this in itself does not indicate a problem. Kris pgp1p3N8rGDBr.pgp Description: PGP signature
Re: Best practices for using gjournal with gmirror?
On Wed, Jan 10, 2007 at 11:21:01PM -0500, John Nielsen wrote: 5) Finally, how dangerous is this code? I realize it's experimental and only plan to use it with data that has recent backups, but how much should I worry about it blowing up my system or corrupting my files? Just my personal experience, but I've found the gjournal implementation to be extremely stable. I'm not doing anything terribly unusual with it, but both my laptop and my primary workstation use gjournal for all of their filesystems except / and /tmp. On my workstation one of the journaled filesystems (/home) is on a mirror using the ataraid(4) driver, but I've also successfully used it with gmirror. I do a lot of parallel source code extraction and building and have never run into a crash or panic that was caused by gjournal itself. The panics and deadlocks I have encountered due to other reasons have shown that using gjournal has actually significantly reduced the amount of FS corruption in those events. You still lose anything created or changed in the last ~30 seconds or so, but that's better than a corrupted FS. I would still be religious about backups just in case, but it's unlikely that gjournal will be the reason you have to use them. Craig * NOTE: I'm running the gjournal backport to RELENG_6. YMMV if running -CURRENT. ___ 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
In [EMAIL PROTECTED], Lamont Granquist [EMAIL PROTECTED] typed: On Thu, 11 Jan 2007, Mike Meyer wrote: In [EMAIL PROTECTED], Vulpes Velox [EMAIL PROTECTED] typed: LDAP is nice organizing across many systems, but if you are just dealing with one computer it is complete over kill for any thing. In that situation, it's not merely overkill, it's may actually be a bad idea. Can you say AIX SDR? How about Windows registry? And then you take the windows registry from 1,000 machines and cram them into a centralized database and try to manage the resultant mess. I don't think this is a good solution. The difference is that when a single machine crashes, you can use a *different* machine to examine/fix the centralized database while you're working on that machine. If you just cram all the values into the central database, then you're no better off than you would be with flat files on every host. If, on the other hand, you organize the data in the database to reflect the organization of the systems, you can leverage things to cut down on the amount of work you have to do to propogate changes. Someone else mentioned rsync, and that works fairly well, though I prefer perforce. However, it's not quite as flexible - or as convenient - as a database. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ 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 Thursday 11 January 2007 09:56 am, Darren Pilgrim wrote: Mike Meyer wrote: In [EMAIL PROTECTED], Vulpes Velox [EMAIL PROTECTED] typed: LDAP is nice organizing across many systems, but if you are just dealing with one computer it is complete over kill for any thing. In that situation, it's not merely overkill, it's may actually be a bad idea. Can you say AIX SDR? How about Windows registry? Those system both took the approach of putting all the configuration information in a central database. This creates problems because the tools needed to examine/fix the config database require a complex environment - at least compared to a statically linked copy of ed. LDAP may not be so bad, but it still makes me nervous. On the other hand, if you've got a flock of boxes to manage, having a way to tell the rc subsystem Go read config values from this LDAP server seems like a very attractive alternative. And to think, all these years I've been wasting my time and effort using NFS and rsync to centralize the configurations of server farms. I think (Mike will have to confirm/deny) what Mike was trying to say was that for a single system, a centralised database for configuration options was overkill and a problem. Using the Windows Registry as an example. But, using a centralised database for configuring dozens of systems (similar or otherwise) could be a good idea, and that LDAP may be good in that situation (a lot of reading going on at boot to create the configs). -- Freddie Cash [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: re(4) incorrect checksum
On Thu, Jan 11, 2007 at 04:37:05PM +0100, Rene Ladan wrote:
Pyun YongHyeon schreef:
On Thu, Jan 11, 2007 at 12:14:34PM +0100, Rene Ladan wrote:
Pietro Cerutti schreef:
Hi lists,
FreeBSD gahrtop.localhost 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #1:
Tue Jan 9 19:34:13 CET 2007
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GAHRTOP i386
CPU: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz (2000.15-MHz
686-class CPU)
Cores per package: 2
re0: RealTek 8168B/8111B PCIe Gigabit Ethernet port 0xc800-0xc8ff
mem 0xff2ff000-0xff2f irq 17 at device 0.0 on pci2
($FreeBSD: src/sys/dev/re/if_re.c,v 1.46.2.20 2006/09/21 11:08:28
yongari Exp $)
I get checksum errors on every packet I send, example:
Checksum: 0x0bc5 [incorrect, should be 0x78fe (maybe caused by
checksum offloading?)]
I think this could be the cause of some web pages (e.g. Gmail in
standard view [html view works well]) not to be displayed.
I tracked down the problem to the re(4) driver just because wlan works
good...
Any ideas?
I'm also seeing these www problems with my re(4) card (chipid
0x816810ec), see
http://lists.freebsd.org/pipermail/freebsd-current/2006-December/068333.html
Does your re(4) also work when you disable checksum offload?
Yes, 'ifconfig re0 -txcsum' does the trick.
re0: RealTek 8168/8111B PCIe Gigabit Ethernet port 0xc800-0xc8ff mem
0xfe0ff000-0xfe0f irq 16 at device 0.0 on pci2
if.re.c revision 1.80 2006/12/20 02:13:59 marius
I've never encountered checksum offload issue after wpaul's fix.
How about attached one? It's just vague guess but please give it
try and let me know the result.
--
Regards,
Pyun YongHyeon
Index: if_re.c
===
RCS file: /home/ncvs/src/sys/dev/re/if_re.c,v
retrieving revision 1.80
diff -u -r1.80 if_re.c
--- if_re.c 20 Dec 2006 02:13:59 - 1.80
+++ if_re.c 12 Jan 2007 01:42:59 -
@@ -2027,9 +2027,9 @@
arg.rl_flags = RL_TDESC_CMD_LGSEND |
((uint32_t)(*m_head)-m_pkthdr.tso_segsz
RL_TDESC_CMD_MSSVAL_SHIFT);
- else {
- if ((*m_head)-m_pkthdr.csum_flags CSUM_IP)
- arg.rl_flags |= RL_TDESC_CMD_IPCSUM;
+ else if (((*m_head)-m_pkthdr.csum_flags
+ (CSUM_IP | CSUM_TCP | CSUM_UDP)) != 0) {
+ arg.rl_flags |= RL_TDESC_CMD_IPCSUM;
if ((*m_head)-m_pkthdr.csum_flags CSUM_TCP)
arg.rl_flags |= RL_TDESC_CMD_TCPCSUM;
if ((*m_head)-m_pkthdr.csum_flags CSUM_UDP)
___
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
Mike Meyer wrote: In [EMAIL PROTECTED], Vulpes Velox [EMAIL PROTECTED] typed: LDAP is nice organizing across many systems, but if you are just dealing with one computer it is complete over kill for any thing. In that situation, it's not merely overkill, it's may actually be a bad idea. Can you say AIX SDR? How about Windows registry? Those system both took the approach of putting all the configuration information in a central database. This creates problems because the tools needed to examine/fix the config database require a complex environment - at least compared to a statically linked copy of ed. LDAP may not be so bad, but it still makes me nervous. On the other hand, if you've got a flock of boxes to manage, having a way to tell the rc subsystem Go read config values from this LDAP server seems like a very attractive alternative. mike Ok, so the general consensus seems to be that it's a good idea in some cases and not in others. I myself agree that it should not be part of the base setup for issues regarding the complication of the base distribution... but why not make a package for it? Take this idea, and run with it... build a package that installs over the base installation, bundling the LDAP client libs, new rc structure, tools, etc all in one shot. Add it to the ports collection and call it done. - After all that's the wonder that is opensource... if ya want to improve something, go for it - even better if you can contribute your additions back to the community. I think it could be the start of something really handy for those out there managing large banks of servers... a central configuration repository, key-based or something where you take a freshly installed server, and point it to a config 'key', reboot and poof! That server goes down, simply tell a spare one to use it's config 'key' and reboot - back up and running :) You'd get all the redundancy of LDAP, the organization of a directory tree, and the simplicity of uniform configuration information. This of course with some assumptions about storage and backup situations, but hey - it's an idea not a reality here I'm talking about. Anyways... without digressing way too much, my point was this: if there's enough people interested in the idea, then collaborate and by all means try to make something of it. If it works out well, lots of people start adopting it, THEN we (the FreeBSD community) should look at including it as part of the base... until then, make it as a bundled package or something. I'm using LDAP here for users, groups, email and account information shared to many servers - and it works great, but it's certainly not for everyone and I'd never expect it to come out-of-the box with everything required to do so. Have to weigh the benefits against the costs. This thread keeps arguing the good or the bad points of doing this - and it seems to me not something worth arguing the merits of. If you believe in it enough, then do it or at least try it. Lets move on from if we should or shouldn't, and look more to HOW we could... Just my two and a half cents. -- Nathan Vidican [EMAIL PROTECTED] Windsor Match Plate Tool Ltd. http://www.wmptl.com/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Looking for help with schedgraph; phython/tkinter programming.
I'm looking for someone who might like to help implement new features in schedgraph. This is /usr/src/tools/sched/schedgraph.py. Schedgraph graphs scheduler and system load behavior, sort of like a graphical top. Some example output is here: http://www.chesapeake.net/~jroberson/schedgraph.jpg Some of the features I'd be interested in are: 1) Sortable and mutable thread listings. 2) A seperate per-cpu line that displays which thread is presently running 3) Support for graphing generic counters provided via KTR. 4) Various other stats/cleanup/beautification/etc. Please keep me in the cc list on replies. Any hackers interested? Thanks, Jeff ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for help with schedgraph; phython/tkinter programming.
Jeff Roberson wrote: I'm looking for someone who might like to help implement new features in schedgraph. This is /usr/src/tools/sched/schedgraph.py. Schedgraph graphs scheduler and system load behavior, sort of like a graphical top. Some example output is here: http://www.chesapeake.net/~jroberson/schedgraph.jpg Some of the features I'd be interested in are: 1) Sortable and mutable thread listings. 2) A seperate per-cpu line that displays which thread is presently running I think rwatson had a tool that does that.. 3) Support for graphing generic counters provided via KTR. 4) Various other stats/cleanup/beautification/etc. Please keep me in the cc list on replies. Any hackers interested? Thanks, Jeff ___ 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]
[SOLVED] re(4) incorrect checksum
Hi lists, ifconfig re0 -txcsum -rxcsum solved the problem Anyway, is this a bug in the driver or in the interface itself? Thanx, regards -- Forwarded message -- From: Pietro Cerutti [EMAIL PROTECTED] Date: Jan 11, 2007 11:29 AM Subject: re(4) incorrect checksum To: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org Hi lists, FreeBSD gahrtop.localhost 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #1: Tue Jan 9 19:34:13 CET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GAHRTOP i386 CPU: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz (2000.15-MHz 686-class CPU) Cores per package: 2 re0: RealTek 8168B/8111B PCIe Gigabit Ethernet port 0xc800-0xc8ff mem 0xff2ff000-0xff2f irq 17 at device 0.0 on pci2 ($FreeBSD: src/sys/dev/re/if_re.c,v 1.46.2.20 2006/09/21 11:08:28 yongari Exp $) I get checksum errors on every packet I send, example: Checksum: 0x0bc5 [incorrect, should be 0x78fe (maybe caused by checksum offloading?)] I think this could be the cause of some web pages (e.g. Gmail in standard view [html view works well]) not to be displayed. I tracked down the problem to the re(4) driver just because wlan works good... Any ideas? Thanx, -- Pietro Cerutti ICQ: 117293691 PGP: 0x9571F78E - ASCII Ribbon Campaign - against HTML e-mail and proprietary attachments www.asciiribbon.org -- Pietro Cerutti ICQ: 117293691 PGP: 0x9571F78E - ASCII Ribbon Campaign - against HTML e-mail and proprietary attachments www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
re(4) incorrect checksum
Hi lists, FreeBSD gahrtop.localhost 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #1: Tue Jan 9 19:34:13 CET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GAHRTOP i386 CPU: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz (2000.15-MHz 686-class CPU) Cores per package: 2 re0: RealTek 8168B/8111B PCIe Gigabit Ethernet port 0xc800-0xc8ff mem 0xff2ff000-0xff2f irq 17 at device 0.0 on pci2 ($FreeBSD: src/sys/dev/re/if_re.c,v 1.46.2.20 2006/09/21 11:08:28 yongari Exp $) I get checksum errors on every packet I send, example: Checksum: 0x0bc5 [incorrect, should be 0x78fe (maybe caused by checksum offloading?)] I think this could be the cause of some web pages (e.g. Gmail in standard view [html view works well]) not to be displayed. I tracked down the problem to the re(4) driver just because wlan works good... Any ideas? Thanx, -- Pietro Cerutti ICQ: 117293691 PGP: 0x9571F78E - ASCII Ribbon Campaign - against HTML e-mail and proprietary attachments www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Fwd: [SOLVED] re(4) incorrect checksum
On 1/11/07, Bernd Walter [EMAIL PROTECTED] wrote: On Thu, Jan 11, 2007 at 11:51:51AM +0100, Pietro Cerutti wrote: Hi lists, ifconfig re0 -txcsum -rxcsum solved the problem Anyway, is this a bug in the driver or in the interface itself? That is how checksum offloading works. tcpdump can't see a correct checksum, because it is not calculated by the kernel and left for the hardware. Yes, I got it. However checksum offloading is broken for re(4) based cards, therefor it is disabled by default. I don't think so at least, I did nothing to enable it, but it were indeed enabled (RXCSUM,TXCSU showed up in the options field shown by ifconfig) -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][EMAIL PROTECTED] -- Pietro Cerutti ICQ: 117293691 PGP: 0x9571F78E - ASCII Ribbon Campaign - against HTML e-mail and proprietary attachments www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [SOLVED] re(4) incorrect checksum
On Thu, Jan 11, 2007 at 11:51:51AM +0100, Pietro Cerutti wrote: Hi lists, ifconfig re0 -txcsum -rxcsum solved the problem Anyway, is this a bug in the driver or in the interface itself? That is how checksum offloading works. tcpdump can't see a correct checksum, because it is not calculated by the kernel and left for the hardware. However checksum offloading is broken for re(4) based cards, therefor it is disabled by default. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][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: [SOLVED] re(4) incorrect checksum
On Thu, Jan 11, 2007 at 11:51:51AM +0100, Pietro Cerutti wrote: Hi lists, ifconfig re0 -txcsum -rxcsum solved the problem In if_re.c, rev 1.46.2.18 wpaul@ fixed a long standing checksum offload issue by padding. Does re(4) work when you disable only Tx checksum offload?(i.e. ifconfig re0 -txcsum) Anyway, is this a bug in the driver or in the interface itself? Thanx, regards -- Forwarded message -- From: Pietro Cerutti [EMAIL PROTECTED] Date: Jan 11, 2007 11:29 AM Subject: re(4) incorrect checksum To: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org Hi lists, FreeBSD gahrtop.localhost 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #1: Tue Jan 9 19:34:13 CET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GAHRTOP i386 CPU: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz (2000.15-MHz 686-class CPU) Cores per package: 2 re0: RealTek 8168B/8111B PCIe Gigabit Ethernet port 0xc800-0xc8ff mem 0xff2ff000-0xff2f irq 17 at device 0.0 on pci2 ($FreeBSD: src/sys/dev/re/if_re.c,v 1.46.2.20 2006/09/21 11:08:28 yongari Exp $) I get checksum errors on every packet I send, example: Checksum: 0x0bc5 [incorrect, should be 0x78fe (maybe caused by checksum offloading?)] I think this could be the cause of some web pages (e.g. Gmail in standard view [html view works well]) not to be displayed. I tracked down the problem to the re(4) driver just because wlan works good... Any ideas? Thanx, -- Pietro Cerutti ICQ: 117293691 PGP: 0x9571F78E - ASCII Ribbon Campaign - against HTML e-mail and proprietary attachments www.asciiribbon.org -- Pietro Cerutti ICQ: 117293691 PGP: 0x9571F78E - ASCII Ribbon Campaign - against HTML e-mail and proprietary attachments www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- Regards, Pyun YongHyeon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [SOLVED] re(4) incorrect checksum
On 1/11/07, Pyun YongHyeon [EMAIL PROTECTED] wrote: In if_re.c, rev 1.46.2.18 wpaul@ fixed a long standing checksum offload issue by padding. Does re(4) work when you disable only Tx checksum offload?(i.e. ifconfig re0 -txcsum) yes, because -txcsum also disables Rx checksum on my NIC. # ifconfig re0 options=1bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING # ifconfig re0 -txcsum options=18VLAN_MTU,VLAN_HWTAGGING -- Regards, Pyun YongHyeon -- Pietro Cerutti ICQ: 117293691 PGP: 0x9571F78E - ASCII Ribbon Campaign - against HTML e-mail and proprietary attachments www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vpnc problem
Hi Vishal,
First of all you should avoid cross-posting. Additionaly, I don't
think this is a question for [EMAIL PROTECTED]
On Wed, Jan 03, 2007 at 08:50:26PM -0500, Vishal Patil wrote:
I have found the answer to this question. I basically had to edit the
vpnc-script and replace the body of the function get_default_gw with
netstat -r -n | sed 's/default/0.0.0.0/' | grep '^0.0.0.0' | awk '{print
$2}'
So now I have vpnc-0.3.3 working on FreeBSD.
The port stands in security/vpnc, you should use it. It guess the
maintainer has tried it before updating the port and pushed the
appropriate patch into the ports tree.
Regards
--
Jeremie Le Hen
jeremie at le-hen dot org ttz at chchile dot org
___
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nathan Vidican Sent: Friday, 12 January 2007 5:55 AM To: Mike Meyer; [EMAIL PROTECTED] Subject: Re: LDAP integration Mike Meyer wrote: In [EMAIL PROTECTED], Vulpes Velox [EMAIL PROTECTED] typed: LDAP is nice organizing across many systems, but if you are just dealing with one computer it is complete over kill for any thing. In that situation, it's not merely overkill, it's may actually be a bad idea. Can you say AIX SDR? How about Windows registry? Those system both took the approach of putting all the configuration information in a central database. This creates problems because the tools needed to examine/fix the config database require a complex environment - at least compared to a statically linked copy of ed. LDAP may not be so bad, but it still makes me nervous. On the other hand, if you've got a flock of boxes to manage, having a way to tell the rc subsystem Go read config values from this LDAP server seems like a very attractive alternative. mike Ok, so the general consensus seems to be that it's a good idea in some cases and not in others. I myself agree that it should not be part of the base setup for issues regarding the complication of the base distribution... but why not make a package for it? Take this idea, and run with it... build a package that installs over the base installation, bundling the LDAP client libs, new rc structure, tools, etc all in one shot. Add it to the ports collection and call it done. - After all that's the wonder that is opensource... if ya want to improve something, go for it - even better if you can contribute your additions back to the community. I think it could be the start of something really handy for those out there managing large banks of servers... a central configuration repository, key-based or something where you take a freshly installed server, and point it to a config 'key', reboot and poof! That server goes down, simply tell a spare one to use it's config 'key' and reboot - back up and running :) You'd get all the redundancy of LDAP, the organization of a directory tree, and the simplicity of uniform configuration information. This of course with some assumptions about storage and backup situations, but hey - it's an idea not a reality here I'm talking about. Anyways... without digressing way too much, my point was this: if there's enough people interested in the idea, then collaborate and by all means try to make something of it. If it works out well, lots of people start adopting it, THEN we (the FreeBSD community) should look at including it as part of the base... until then, make it as a bundled package or something. I'm using LDAP here for users, groups, email and account information shared to many servers - and it works great, but it's certainly not for everyone and I'd never expect it to come out-of-the box with everything required to do so. Have to weigh the benefits against the costs. This thread keeps arguing the good or the bad points of doing this - and it seems to me not something worth arguing the merits of. If you believe in it enough, then do it or at least try it. Lets move on from if we should or shouldn't, and look more to HOW we could... Just my two and a half cents. -- Nathan Vidican [EMAIL PROTECTED] Windsor Match Plate Tool Ltd. http://www.wmptl.com/ I would be in favour of this being put together asa port.. says he looking into the future where a multi server / multi service 'system' is lurking. Might be nice for configuring blade server arrays too. mjt Murray Taylor Special Projects Engineer Bytecraft Systems E: [EMAIL PROTECTED] -- Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. --Albert Einstein --- The information transmitted in this e-mail is for the exclusive use of the intended addressee and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of it, or the taking of any action in reliance upon this information by persons and/or entities other than the intended recipient is prohibited. If you received this in error, please inform the sender and/or addressee immediately and delete the material. E-mails may not be secure, may contain computer viruses and may be corrupted in transmission. Please carefully check this e-mail (and any attachment) accordingly. No warranties are given and no liability is accepted for any loss or damage caused by such matters. --- ### This e-mail message has been scanned for Viruses by Bytecraft ### ___
Re: sbrk vs mmap
darran kartaschew wrote: Hi Guys, I'm having some issues with rewriting a simple malloc() function to be with FreeBSD (AMD64). This is part of porting an application from Linux to FreeBSD. After pulling my hair out for a while, I've found that the sbrk() system call just returns 45 - Operation Not Supported error, irrespective of the parameters passed to it. (I've found the source for sbrk() and see that it's not implemented). So I decided to try using mmap() instead. All memory allocations don't have to be continuous, so mmap() will suffice. The problem is I'm getting an invalid file handle error? According to the man page, if you use MAP_ANON you're just allocating a block of memory without linking to a file, and a handle of -1 should be supplied... Any way code is as follows: memInit: mov r4, 0 ; don't care where the memory is allocated mov r5, 1048576 ; alloc 1MB mov r3, 3 ; RW access to memory mov r2, 4096 ; MAP_ANON - not a file mov r8d, -1 ; -1 for file handle if using MAP_ANON mov r9, 0 ; ignored for MAP_ANON mov r0, 197 ; mmap(); syscall mov qword [_mmap], r0 ; save address so we can release it on exit; ret It fails with an EBADF (9) ; Bad File Descriptor error... Note: r0 = rax, r1 = rbx, r2 = rcx, r3 = rdx, r4 = rdi, r5 = rsi, r6 = rbp, r7 = rsp. Various parameters for mmap() are found in mman.h. So does anyone have an example of a working call to mmap() or tell me what's wrong with the above code? I've done up a test C program that simple calls mmap(), after tracing through the compiled C program using gdb I can't see that I'm doing anything different to what gcc/glibc are doing? (except the macro expansion that's in libc which adds an additional 0 to the top of the stack). PS. FASM 1.66 running on FreeBSD 6.1 (AMD64). PPS. This is NOT a homework assignment! (tm) :P I think you are missing a parameter. mmap (as well as pwrite, lseek, truncate and ftruncate), has a hidden parameter just before the offset that is ignored, due to a bug in ancient GCC versions. So, basically, you should also push a 0 on the stack. Take a look at src/sys/libc/sys/mmap.c . I have a patch to remove this useless argument, but haven't committed it yet. -- Suleiman ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
