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: LDAP integration
On Tue, 9 Jan 2007, Vulpes Velox wrote: The why is because I like centralized management and it would be really handy for that. For my use, it would be handy in regards to my laptops. I feel better central management is extreme significant. If I had nothing more to say than this would be neat! we would not still be talking. Right now I am just poking around for other people I regards to searching the archives, I am not seeing any thing in regards to LDAP outside of NSS recently. I am also not finding any thing in regards to dynamically and automatically building various config files. Why are you doing this in the FreeBSD rc scripts directly? Why not install cfengine and work on making cfengine play better with database-driven config? 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. That gets away from the need to tweak and edit the /etc/rc.conf config file with multiple inputs tweaking a single file. Instead you can drop whole orthogonal fragments into /etc/rc.conf.d/inetd to manage the inetd config which would make it more friendly to radmind-like approaches. It also makes it easier to use with cfengine since orthogonal cfengine modules aren't doing editfiles touches to the same files. The /etc/cron.d directory that (most?) linux distros have is similarly very useful to drop in files that contain completely orthogonal config (and may be written by entirely different config management tools -- e.g. system config management vs. application deployment/management), and the /etc/periodic functionality is not flexible enough to cover all cases. ___ 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, 10 Jan 2007, Doug Barton wrote: Lamont Granquist wrote: Why are you doing this in the FreeBSD rc scripts directly? Why not install cfengine and work on making cfengine play better with database-driven config? Indeed. For a many systems problem, cfengine is a great tool. I think the OP is more interested in the dynamically configured laptop problem, which is also an interesting/difficult one, but I don't think it's a good problem for LDAP to solve. It still feels like I have LDAP that I want to use as a solution, so what problem can I point it at? to me. Yeah, I've also found LDAP to be more of a problem than a solution itself. Once the data starts to be dynamically updated and acquires a higher rate of change you no longer have a 'directory service' that you're working with and MySQL becomes a better tool than LDAP. System config has a way of creeeping into becoming more dynamic over time, particularly when you start logging audit trails in the database, success codes, error conditions, state machines, etc. 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... That gets away from the need to tweak and edit the /etc/rc.conf config file with multiple inputs tweaking a single file. Instead you can drop whole orthogonal fragments into /etc/rc.conf.d/inetd to manage the inetd config which would make it more friendly to radmind-like approaches. It also makes it easier to use with cfengine since orthogonal cfengine modules aren't doing editfiles touches to the same files. Yes yes yes all around. At one time I suggested that we add support for /usr/local/etc/rc.conf.d and encourage port authors to drop files in there, but I didn't get much enthusiasm for it. Perhaps it's time to revisit that? sounds great to me, but i don't have the CFT The /etc/cron.d directory that (most?) linux distros have is similarly very useful to drop in files that contain completely orthogonal config (and may be written by entirely different config management tools -- e.g. system config management vs. application deployment/management), and the /etc/periodic functionality is not flexible enough to cover all cases. That's not a bad idea, but you'll have to find some other huckleberry to address it, I've got my hands full at the moment. yup, hear ya. ___ 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, 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...
Basically I like self-containment around a top-down role that the server
plays ('i am an ftp server') not necessarily around a bottom-up subsystem
like inetd... YMMV.
___
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, 10 Jan 2007, Vulpes Velox 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. That gets away from the need to tweak and edit the /etc/rc.conf config file with multiple inputs tweaking a single file. Instead you can drop whole orthogonal fragments into /etc/rc.conf.d/inetd to manage the inetd config which would make it more friendly to radmind-like approaches. It also makes it easier to use with cfengine since orthogonal cfengine modules aren't doing editfiles touches to the same files. The /etc/cron.d directory that (most?) linux distros have is similarly very useful to drop in files that contain completely orthogonal config (and may be written by entirely different config management tools -- e.g. system config management vs. application deployment/management), and the /etc/periodic functionality is not flexible enough to cover all cases. This honestly sounds like a massive and complete pain in the ass. I don't even see how this is remote admin friendly. It just means way more to muck around with. If cfengine can not generate rc.conf in a nice manner, it seems more like a problem with cfengine. Actually, cfengine is perfectly capable of doing that, it has an obscenely flexible ability to edit files 'in place' to do this kind of tweaking and tuning to manage monolithic config files like rc.conf or inetd.conf which may have orthogonal configuration inputs from different apps running on the machine. The problem is that with orthogonal inputs to the same config file it becomes more likely that entirely seperate pieces of config will be twiddling the same file, and those pieces of code will be built and maintained by entirely different people and that increases the chances of simple file editing errors. Once you start hitting the problem of dozens of system admins trying to collaboratively manage 1000s of systems these kinds of issues come up. They're not apparent when you've got single administrative owners for all the machines. The radmind model of system configuration alone, however, doesn't let you do this since it is built around pushing only whole files. You can construct all the different flavors of the monolithic files that you're managing and try to make sure that the correct image gets on the correct system but that requires higher-level wrapping -- or you can just have radmind call out to cfengine to construct files like this. Still, avoiding monolithic files makes system configuration friendlier to those who use the radmind-approach. ___ 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, 10 Jan 2007, Vulpes Velox wrote: On Wed, 10 Jan 2007 13:56:23 -0800 Doug Barton [EMAIL PROTECTED] wrote: Lamont Granquist wrote: Why are you doing this in the FreeBSD rc scripts directly? Why not install cfengine and work on making cfengine play better with database-driven config? Indeed. For a many systems problem, cfengine is a great tool. I think the OP is more interested in the dynamically configured laptop problem, which is also an interesting/difficult one, but I don't think it's a good problem for LDAP to solve. It still feels like I have LDAP that I want to use as a solution, so what problem can I point it at? to me. Stuff like this is what LDAP truely shines for. It keeps everything in a nicely organized manner that is easily accessible and searchable. I agree that database-driven config management is good. I do not agree that LDAP is the best way to go about doing it since LDAP works best as a read-mostly directory service and not as an mixed-read/write database which is what I've seen these kinds of configuration management databases scale and turn into. LDAP is great for stuff that barely ever changes. When you add SOX audit trails and error reporting and other junk into the database LDAP stops being appropriate. I also don't understand the focus on dynamically generating /etc/rc.conf since that is actually not what I want in my database. Inside my database I want to configure a machine as an ftp server or a web server and deal with the high-level roles that the machine plays. In order to generate an rc.conf file I want to take the roles as inputs and construct the rc.conf file specific to the machine. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Yet another magic symlinks implementation
AFS also has an @sys variable which is useful for network filesystem mounted binaries and software for multiple architectures through a single globally unique path: http://www.openafs.org/pages/doc/AdminReference/auarf234.htm#HDRSYS And I'd vote with Oliver on preferring variant symlinks for flexibility: On Mon, 6 Nov 2006, Oliver Fromme wrote: I'm afraid that I don't like NetBSD's magic symlinks very much. It's less flexible than variant symlinks because it only supports a fixed set of variables. As far as I can tell, it does not solve any of the tasks described above. Therefore I would really like to see your port of DragonFly BSD's variant symlinks comitted to FreeBSD. Of course, it could be a compile-time option in case there are people who don't want the code in their kernel at all. But you have to set a sysctl anyway to enable it globally (it's disabled by default on DragonFly). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: matthew dillon
to quote the freebsd-current dmesg: Be nice to each other, mmmkay? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
xmms + RTP_PRIO_REALTIME under -current
I'm getting pops in xmms under -current. Awhile back the realtime
scheduling option for xmms was busted, so I wrote this wrapper script
around xmms. Am I doing the right thing here? Is there anything else I
could do to config -current to eliminate pops? Is -current going to get a
fully-preemptable kernel anytime soon?
#include stdio.h
#include unistd.h
#include sys/types.h
#include sys/rtprio.h
int main(int argc, char *argv[]) {
struct rtprio rtp;
rtp.type = RTP_PRIO_REALTIME;
rtp.prio = 10;
if (rtprio(RTP_SET, 0, rtp) != 0)
perror(rtprio);
setreuid(0,0);
execv(/usr/X11R6/bin/xmms, argv);
perror(execv);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Network block device.
On Wed, 29 Jan 2003, Matthew N. Dodd wrote: What you really want is SCSI over IP. Anything else is just a hack and not to be trusted. And iSCSI isn't? I think that NFS is less of a hack than NBD though. Of course if Linux still suffers from poor NFS performance that might explain why they came up with NBD in the first place. And Linux still suffers from poor NFS stability. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: CVS_LOCAL_BRANCH_NUM?
From the man page, I'm not really sure where it makes a difference other than when someone is playing with IFS, but $@ seems to be more of what I intended... And in case anyone is still reading this now, I'd like to throw out the suggestion that CVS_LOCAL_BRANCH_NUM should really be an option to cvs rtag and should thereby be settable in one's .cvsrc file and the option should get transmitted to the cvs pserver, eliminating the kind of asymmetry I just documented. On Tue, 10 Dec 2002, Dmitry Morozovsky wrote: On Mon, 9 Dec 2002, Lamont Granquist wrote: LG I finally figured this out. To use CVS_LOCAL_BRANCH_NUM with a cvs LG pserver you need to have the environment variable set server-side. That LG means something like invoking a wrapper from inetd which sets the LG environment variable and the calls cvs. LG LG Completely undocumented behavior and not terribly transparent. LG LG I'm working on some instructions at: LG LG http://www.scriptkiddie.org/freebsd/setting_up_local_repo.html A little comment: - 8 - wrapper #!/bin/sh export CVS_LOCAL_BRANCH_NUM=1000 /usr/bin/cvs $* - 8 - Don't you think the last parameter should be $@ ? Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: CVS_LOCAL_BRANCH_NUM?
On Tue, 10 Dec 2002, Dmitry Morozovsky wrote: On Tue, 10 Dec 2002, Lamont Granquist wrote: LG From the man page, I'm not really sure where it makes a difference other LG than when someone is playing with IFS, but $@ seems to be more of what I LG intended... Please note quotes explicitly, $@ is really needed where your parameters contain spaces (bad practice in filenames, yeah, but don't make yourself another one PITA you can avoid ;-P ) got it. LG And in case anyone is still reading this now, I'd like to throw out the LG suggestion that CVS_LOCAL_BRANCH_NUM should really be an option to cvs LG rtag and should thereby be settable in one's .cvsrc file and the option LG should get transmitted to the cvs pserver, eliminating the kind of LG asymmetry I just documented. I do agree; however, as cvs is a contributed software, this should be discussed and/or reported via cvsbug(8). Actually CVS_LOCAL_BRANCH_NUM is a local hack in FreeBSD, and which originated with FreeBSD, so freebsd-hackers is as good a place as any to bitch about it... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: CVS_LOCAL_BRANCH_NUM?
I finally figured this out. To use CVS_LOCAL_BRANCH_NUM with a cvs pserver you need to have the environment variable set server-side. That means something like invoking a wrapper from inetd which sets the environment variable and the calls cvs. Completely undocumented behavior and not terribly transparent. I'm working on some instructions at: http://www.scriptkiddie.org/freebsd/setting_up_local_repo.html On Sun, 8 Dec 2002, Lamont Granquist wrote: I've been struggling all weekend to setup a local CVS repo mirror, and I guess I've done that successfully, but I can't figure out what is going on with CVS_LOCAL_BRANCH_NUM. My understanding is that if I set it to a large number 63000 that it should tag branches that I make with values roughly that large. You can see from below that what I'm getting though is low-numbered branches. I'm confused. This is what I did on both -current and 4.6-release: setenv CVS_LOCAL_BRANCH_NUM 63000 cvs rtag -b -r RELENG_4_7 RELENG_4_LCG src And this is what I get -- shouldn't that be something like 1.229.63000? cvs status UPDATING === File: UPDATING Status: Up-to-date Working revision:1.229 Repository revision: 1.229 /cvs/src/UPDATING,v Sticky Tag: RELENG_4_LCG (branch: 1.229.4) Sticky Date: (none) Sticky Options: (none) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
CVS_LOCAL_BRANCH_NUM?
I've been struggling all weekend to setup a local CVS repo mirror, and I guess I've done that successfully, but I can't figure out what is going on with CVS_LOCAL_BRANCH_NUM. My understanding is that if I set it to a large number 63000 that it should tag branches that I make with values roughly that large. You can see from below that what I'm getting though is low-numbered branches. I'm confused. This is what I did on both -current and 4.6-release: setenv CVS_LOCAL_BRANCH_NUM 63000 cvs rtag -b -r RELENG_4_7 RELENG_4_LCG src And this is what I get -- shouldn't that be something like 1.229.63000? cvs status UPDATING === File: UPDATING Status: Up-to-date Working revision:1.229 Repository revision: 1.229 /cvs/src/UPDATING,v Sticky Tag: RELENG_4_LCG (branch: 1.229.4) Sticky Date: (none) Sticky Options: (none) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
help compiling propolice gcc
I'm trying to follow these instructions to build 4.7 with the propolice modifications to the gcc compiler: http://www.trl.ibm.com/projects/security/ssp/buildfreebsd.html I'm starting with an absolutely fresh cvs checkout and i've nuked my /usr/obj tree. What I'm getting is in this step: cd /usr/src/gnu/usr.bin/cc make depend make all install I'm getting this error in the build: -- cc -O -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr\ -I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I. -static -o cc1 c-parse.o c-lang.o c-decl.o c-lex.o /usr/src/gnu/usr.bin/cc/cc1/../cc_int/libcc_int.a cc: /usr/src/gnu/usr.bin/cc/cc1/../cc_int/libcc_int.a: No such file or directory *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc/cc1. *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc. And if I try to go into /usr/src/gnu/usr.bin/cc/cc_int and do a make I get only this: Warning: Object directory not changed from original /usr/src/gnu/usr.bin/cc/cc_int Can anyone suggest how to build gcc standalone like this? Or if that shouldn't be supported is there a better build procedure that you should follow to upgrade to the propolice compiler? I know I could build+install the world and then do it again to recompile with propolice, but a shortcut in that process would be a good thing. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: help compiling propolice gcc
On Sun, 8 Dec 2002, Kris Kennaway wrote: On Sun, Dec 08, 2002 at 05:22:24PM -0800, Lamont Granquist wrote: And if I try to go into /usr/src/gnu/usr.bin/cc/cc_int and do a make I get only this: Warning: Object directory not changed from original /usr/src/gnu/usr.bin/cc/cc_int This indicates you probably have stale cruft in your source tree. Do the following: cd /usr/src make cleandir make cleandir and try again. nope, it was *clean*, i did an rm -rf /usr/src /usr/obj and then a fresh checkout into /usr/src. i made it work using something like: cd /usr/src/gnu/usr.bin/cc make depend cd /usr/src/gnu/usr.bin/cc/cc_int make libcc_int.a cd /usr/src/gnu/usr.bin/cc/cc_fbsd make libcc_fbsd.a cd /usr/src/gnu/usr.bin/cc make all install (if anyone else is interested in propolice i had to add protector.c to the cc_int/Makefile, my initial test program seems to be succesful -- if i get a succesful world out of it, i'll post instructions and fresh diff against 4.7) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: help compiling propolice gcc
On Sun, 8 Dec 2002, Garance A Drosihn wrote: If you're going to jump into the middle of /usr/src to make something, then you should probably do: cd /usr/src/gnu/usr.bin/cc make obj make depend ...etc Thanks, that seems to have worked. I couldn't get libc to compile though. What does the build process use the system libc for? Are the static binaries compiled against that? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Shrinking /(s)bin: A Proposal
RedHat systems have only two statically linked binaries in their systems and it is one of the things that I viscerally hate about RedHat. You have to look on another system or lookup on the net which shell to use instead of /sbin/init and then play around with a massively minimal set of things you can do to the filesystem in order to fix your system. I hate that. I particularly hate that because whenever it comes up I just did something stupid enough to nuke my libc and I'm not a happy camper. I want to just boot into single user and fix the system. Also, the lack of 'mv' being statically linked is what caused me to learn so much about how to recover from libc being nuked on RedHat boxes. Its good to have any common utilities people might think of to use to update libc to be statically linked. Of course I can see where on early-90s era systems, or on embedded systems, you'd want to go with the smallest /[s]bin you can get in which case the buildworld option makes perfect sense. I have no use for this option though. I'm happy to gleefully burn through the 20MB of disk space. 20MB of disk space is cheap these days -- 99% of FreeBSD users will never notice that it is gone... On Fri, 15 Nov 2002, Peter Wemm wrote: Robert Watson wrote: On Thu, 14 Nov 2002, Doug Rabson wrote: : I'm open to patches for building /[s]bin as dynamic. If you have : time and can coordinate with [EMAIL PROTECTED] to build the patch, I : would appreciate it. % make NOSHARED=NO buildworld No patches necessary. We do this all the time at work, and it works fabulously. I do this for disk based systems that have / and /usr on the same file system too. To do it right for split root/usr installations requires a few patches though. The rtld and the libs required for /[s]bin need to move to / and compat symlinks created from /usr. A suitable crunchgen'ed binary for /recover would be useful too. I had some local patches that did a subset of this -- moved ld.so to /lib, as well as installing shared libraries to /lib instead of /usr/lib for the base system. I seem to recall I also had to tweak some defaults in ld.so or rtld or the like, though. I agree that the right path to support fully dynamic systems properly is to adopt the approach taken by NetBSD: provide a decent /recover with crunchgen, etc. I do use fully dynamic stuff for some local test boxes, makes upgrading libc code for development purposes much easier, as well as supporting dlsym() for /sbin, which is very useful in my environment. For what its worth: peter@daintree[4:55pm]/rescue-222# ls -sh@dumpfs@ ipmon@ mount_portalfs@ rm@ [@ dumpon@ ipnat@ mount_std@ rmdir@ adjkerntz@ echo@ kenv@ mount_udf@ route@ atacontrol@ ed@ kill@ mount_umapfs@ routed@ badsect@expr@ kldconfig@ mount_unionfs@ rtsol@ camcontrol@ fdisk@ kldload@mv@ savecore@ cat@fdisk_pc98@ kldstat@natd@ setfacl@ ccdconfig@ fsck@ kldunload@ newfs@ sh@ chio@ fsck_ffs@ ldconfig@ newfs_msdos@shutdown@ chmod@ fsck_msdosfs@ ln@ nfsiod@ slattach@ clri@ fsdb@ ls@ nos-tun@sleep@ comcontrol@ fsirand@mca@pax@spppcontrol@ conscontrol@gbde@ md5@ping@ startslip@ cp@ getfacl@mdconfig@ ping6@ stty@ date@ gpt@mdmfs@ ps@ swapon@ dd@ growfs@ mkdir@ pwd@sync@ devd@ hostname@ mknod@ quotacheck@ sysctl@ devfs@ ifconfig@ mount@ raidctl@test@ df@ init@ mount_cd9660@ rcorder@tunefs@ dhclient@ ip6fw@ mount_ext2fs@ rcp@umount@ disklabel@ ipf@mount_msdosfs@ realpath@ dmesg@ ipfs@ mount_nfs@ reboot@ domainname@ ipfstat@mount_ntfs@ rescue* dump@ ipfw@ mount_nullfs@ restore@ peter@daintree[4:55pm]/rescue-223# ls -l ./rescue -rwxr-xr-x 1 root wheel 2725532 Nov 15 16:52 ./rescue* peter@daintree[4:55pm]/rescue-224# ./sh # ./ls -l ./rescue -rwxr-xr-x 1 root wheel 2725532 Nov 15 16:52 ./rescue That's 2.7M to replace roughly 30M of /bin + /sbin. Warner quoted some numbers for a dynamic / case. I think we'd be looking in the order of a few megs of shared libs, plus about 2MB for /bin+/sbin. ie: a reduction from ~30M to somewhere in the area of about 7MB, and that includes the crunched static /rescue/*. This might actually fit on my SMP Pentium-90 box that was installed late 1995. :-) I didn't
Re: Just a wild idea
On Sun, 22 Sep 2002, Juli Mallett wrote: Maybe just replace all suser(9) uses with MAC credential checks, and install MAC_UNIX by default, which would be set up to behave like ye olden UNIX... Who knows. Something like that sounds like a really good idea. I'd like to see this not only for binding to low ports but also, for example, to set the system time -- this would let you run ntpd as non-root. It'd be interesting to have a system one day where once you've gone past single user mode, root drops all its privs and acts just like a normal user account and daemon accounts only have special privs handed out to them in little chunks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: inuring FreeBSD to the apache bug without upgrading apache ?
I think that libsafe would protect against this bug to at least prevent against any possible malicious code execution. I think it still leaves the DoS possibility open though... Even some kind of non-exec stack protection patched into FBSD would only generate a SEGV if it got triggered[*]. Very hard to stop the DoS. [*] and yes does nothing to prevent against malicious code execution attacks on x86 architecture either, only obscures... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Cyrus vs. UW IMAP (was: Re: I Volunteer)
On Thu, 20 Jun 2002, Terry Lambert wrote: Lamont Granquist wrote: Cyrus imapd is a real pain in the ass to administer local user accounts with though. You mean that it doesn't integrate well with the UNIX credentials system. THe issue here is that Cyrus needs to be able to hook create/delete actions on accounts, and UNIX fails to provide a means of doing this. I look at this as a UNIX deficiency. You can actually get around it by using pw and utilizing the script hooks it has. Well, that's trying to place blame on how it should get fixed. From my perspective I don't care, it is just more difficult to use. The easiest real fix for this would be to write a PAM module to cause the UNIX users to authenticate against the Cyrus database. Creating mailboxes is also a PITA, I like procmail to be able to do this and not have a 2nd configuration step... The cyradm program is extremely deficient. Not a big issue, I think. Writing scripts to encapsulate it and be less deficient is really very trivial. Yeah, these days I don't have that much time to script... If I did have more scripting time, I'd be fixing more shit at work to help me sleep through the night when I'm on call... Its great if you want to offer people imap e-mail without offering them shell access. For local access, though, there's a higher administrative overhead. I'm back to using the UW imapd even though I know it is a poorer codebase... I recommend you do not publicize the IP addresses of the servers, if they are net accessible outside your organization. 8-). Nope. Well protected by firewall in one case, and I'll be updating my ipf rules when I convert scriptkiddie... I never use remote IMAP anyways... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: inuring FreeBSD to the apache bug without upgrading apache ?
On Fri, 21 Jun 2002, Kris Kennaway wrote: On Thu, Jun 20, 2002 at 07:33:54PM -0700, Frank Mayhar wrote: Kris Kennaway wrote: Surely it's easier to just upgrade the apache port, instead of recompiling your kernel and the entire OS. Not always. (I'm running an old version of Covalent Raven SSL and I'm loathe to upgrade. If it works, don't fix it and there are only so many hours in a day.) The exact same argument can be made for not upgrading the OS, which is a much larger endeavour and can potentially screw things up much worse. You can just patch the running version of apache with the diffs that fix the security hole. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Cyrus vs. UW IMAP (was: Re: I Volunteer)
Cyrus imapd is a real pain in the ass to administer local user accounts with though. The cyradm program is extremely deficient. Its great if you want to offer people imap e-mail without offering them shell access. For local access, though, there's a higher administrative overhead. I'm back to using the UW imapd even though I know it is a poorer codebase... On Thu, 20 Jun 2002, Terry Lambert wrote: Jason Andresen wrote: Brandon D. Valentine wrote: On Tue, 18 Jun 2002, Darren Pilgrim wrote: It's not exactly FreeBSD, but how about rewriting pine and uw-imap? Last I heard they could use a little work. It would have to be a complete reimplementation thanks to the retarded pine license. Besides, pine has been surpassed and it's called mutt. uw-imap has also been quite surpassed, it's called cyrus. I thought the strength of uw-imap was that it was fairly easy to configure for a machine with local users. The same certainly couldn't be said for Cyrus. Heck, I nearly slit my own wrists out of frustration trying to get Cyrus working. Doesn't help that its online documentation is poo either. The online documentation sucks, but once you understand that you have to use an admin program (cyradm) that has to be able to authenticate to the server in order to manage it, it's not very hard at all. The main problem with UW-IMAP is that it has some serious bugs; not only are there security bugs, but there are tons of bugs in the user libraries -- which is what most people are using for web based mail clients, and other programs... like Pine. The main problem is that there are a lot of instances where it is possible to result in calling unintialized function pointers when you attempt to access a mailbox provider type. The easiest way to see this is to make the function pointer containing struct into a pure virtual base class, each provider into a implementation class for that base class, and then pass around pointers to the provider class coerced to the virtual base class. You'll see all sorts of errors reported by the compiler about the use of a member of a class that can't be, or for which there is not a member function defined. A long time ago, I did this exercise for a commercial company, and found no less than 150 instances where this type of problem existed in the UW IMAP code. My personal recommendation, having contributed patches to both server maintainers, and used both servers in a commercia setting, is that the Cyrus IMAP server is far and away the better code base. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: VM Question (was Re: larger kernel virtual address space)
On Wed, 1 May 2002, David Schultz wrote: Thus spake Lamont Granquist [EMAIL PROTECTED]: Does the FreeBSD VM system do O(1) or O(N) searches for gaps in a processes virtual memory space? I'm not a VM guru, but if I'm reading vm_map.c right, it's O(n) w.r.t. the number of map entries. But since map entries are merged when possible, I would expect the cost to stay fairly low. I know of one app running on Linux/x86 which spends about 40% of its kernel time in get_unmapped_pages() (the Linux equivalent). Trying to mmap() bits and pieces of 20GB worth of data into a 4GB VM space tends to lead to a lot of fragmentation. Be interesting to see if merging would help, but I'd suggest an O(1) algorithm for this. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
VM Question (was Re: larger kernel virtual address space)
Does the FreeBSD VM system do O(1) or O(N) searches for gaps in a processes virtual memory space? (It may not seem obvious why my question is related to the discussion below, but trust me, it is...) On Tue, 30 Apr 2002, David Schultz wrote: Thus spake Rohit Grover [EMAIL PROTECTED]: I apologize for not checking the FAQs before asking the question. http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/advanced.html#CHANGE-KERNEL-ADDRESS-SPACE How large can we make the KVA? This was recently discussed in the thread ``FreeBSD 4.5-STABLE not easily scalable to large servers ... ?'' on the stable and current lists; you'll probably find the information you want in the archives. The short answer is that KVA + UVA = 4 GB on x86. So you could raise KVA to 3 GB, for instance, but then any given user process would only be able to address 1 GB of virtual memory. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
UDP jail bug patch (was Re: (PATCH) Re: jail bug with ircd-hybridin_pcbconnect()?)
I previously posted a patch to fix this UDP-in-jail bug which I believe
may have compromised the security of the jail. This patch shouldn't do
that.
It:
1. preserves the jail check in in_pcbconnect()
2. preserves the laddr+lport check in the beginning of in_pcbbind()
3. modifies no code outside of the jail path
4. only diddles with the PCB laddr which shouldn't have any side effects
because that is exactly what udp_output() is doing to cause the
problem in the first place
Arguably the real fix should be to fix the hash table and the bogosity in
udp_output(), but I don't have the time to commit to that.
--- in_pcb.c.oldMon Mar 18 23:57:57 2002
+++ in_pcb.cTue Mar 19 09:52:45 2002
@@ -501,6 +501,8 @@
int error;
if (inp-inp_laddr.s_addr == INADDR_ANY p-p_prison != NULL) {
+ if (inp-inp_lport != 0)
+ inp-inp_laddr.s_addr = htonl(p-p_prison-pr_ip);
bzero(sa, sizeof (sa));
sa.sin_addr.s_addr = htonl(p-p_prison-pr_ip);
sa.sin_len=sizeof (sa);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
jail bug with ircd-hybrid in_pcbconnect()?
I've been digging through kernel sources trying to figure out this bug
with ircd-hybrid in the ports tree against 4.5-STABLE. The symptom is
that in ircd-hybrid there's a sequence of system calls like this:
sendto(2, \252D\1\0\0\1\0\0\0\0\0\0\00238\003142\003162\003209\7..., 45,
0, {sin_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(63.102.48.45)}}, 16) = 45
sendto(2, \370N\1\0\0\1\0\0\0\0\0\0\21uswest-dsl-142-38\10c..., 48, 0,
{sin_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(63.102.48.45)}}, 16) = -1 EINVAL (Invalid argument)
sendto(2, \221\343\1\0\0\1\0\0\0\0\0\0\21uswest-dsl-142-38\10c..., 48,
0, {sin_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(63.102.48.45)}}, 16) = -1 EINVAL (Invalid argument)
sendto(2, \221\343\1\0\0\1\0\0\0\0\0\0\21uswest-dsl-142-38\10c..., 48,
0, {sin_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(216.17.175.159)}}, 16) = -1 EINVAL (Invalid argument)
(This is obviously a sendto() on a UDP socket that is talking to a DNS
server to do name resolution)
Now, that's inside of a jail. Outside of a jail all of those succeed. I
don't see any reason for those latter 3 to fail inside of jail for any
reasons having to do with the security of the jail. There's also nothing
relevant happening to descriptor 2 in between those system calls.
The latter 3 sendto()s fail in in_pcbconnect() right in the beginning when
it calls in_pcbbind():
in_pcbconnect(inp, nam, p)
register struct inpcb *inp;
struct sockaddr *nam;
struct proc *p;
{
struct sockaddr_in *ifaddr;
struct sockaddr_in *sin = (struct sockaddr_in *)nam;
struct sockaddr_in sa;
int error;
if (inp-inp_laddr.s_addr == INADDR_ANY p-p_prison != NULL) {
bzero(sa, sizeof (sa));
sa.sin_addr.s_addr = htonl(p-p_prison-pr_ip);
sa.sin_len=sizeof (sa);
sa.sin_family = AF_INET;
error = in_pcbbind(inp, (struct sockaddr *)sa, p);
if (error) {
printf(in_pcbconnect error 1\n);
return (error);
}
}
[...snippage...]
And its failing this test in in_pcbbind():
in_pcbbind(inp, nam, p)
register struct inpcb *inp;
struct sockaddr *nam;
struct proc *p;
{
[...]
if (inp-inp_lport || inp-inp_laddr.s_addr != INADDR_ANY) {
printf(in_pcbbind error 4\n);
return (EINVAL);
}
[...]
I'm guessing right now that inp_lport in the pcb is getting set during the
first system call, and causing the subsequent ones to fail. I don't have
all the answers though, and I need to get some sleep... Hoping someone
who understands the pcb functions can point out exactly what the error is
in here -- this is the first time i've ever looked at them...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: jail bug with ircd-hybrid in_pcbconnect()?
On Mon, 18 Mar 2002, Poul-Henning Kamp wrote:
All I can say is that I have had hell with that code and jail, and
you might be right that some cleanup after the first call is missing.
You're probably also the closest person to fix it at this point...
Alright, I'll keep digging.
My guess is that on the first call we've got:
inp-inp_laddr.s_addr == INADDR_ANY
inp-inp_lport == 0
And that after the first call we're supposed to have laddr = jail IP and
lport = emphemeral, but for some reason laddr isn't getting set, so on the
2nd call we've got laddr = INADDR_ANY and lport = emphemeral and that
in_pcbbind() pukes on that.
Poul-Henning
In message [EMAIL PROTECTED], Lamont Granq
uist writes:
I've been digging through kernel sources trying to figure out this bug
with ircd-hybrid in the ports tree against 4.5-STABLE. The symptom is
that in ircd-hybrid there's a sequence of system calls like this:
sendto(2, \252D\1\0\0\1\0\0\0\0\0\0\00238\003142\003162\003209\7..., 45,
0, {sin_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(63.102.48.45)}}, 16) = 45
sendto(2, \370N\1\0\0\1\0\0\0\0\0\0\21uswest-dsl-142-38\10c..., 48, 0,
{sin_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(63.102.48.45)}}, 16) = -1 EINVAL (Invalid argument)
sendto(2, \221\343\1\0\0\1\0\0\0\0\0\0\21uswest-dsl-142-38\10c..., 48,
0, {sin_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(63.102.48.45)}}, 16) = -1 EINVAL (Invalid argument)
sendto(2, \221\343\1\0\0\1\0\0\0\0\0\0\21uswest-dsl-142-38\10c..., 48,
0, {sin_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(216.17.175.159)}}, 16) = -1 EINVAL (Invalid argument)
(This is obviously a sendto() on a UDP socket that is talking to a DNS
server to do name resolution)
Now, that's inside of a jail. Outside of a jail all of those succeed. I
don't see any reason for those latter 3 to fail inside of jail for any
reasons having to do with the security of the jail. There's also nothing
relevant happening to descriptor 2 in between those system calls.
The latter 3 sendto()s fail in in_pcbconnect() right in the beginning when
it calls in_pcbbind():
in_pcbconnect(inp, nam, p)
register struct inpcb *inp;
struct sockaddr *nam;
struct proc *p;
{
struct sockaddr_in *ifaddr;
struct sockaddr_in *sin = (struct sockaddr_in *)nam;
struct sockaddr_in sa;
int error;
if (inp-inp_laddr.s_addr == INADDR_ANY p-p_prison != NULL) {
bzero(sa, sizeof (sa));
sa.sin_addr.s_addr = htonl(p-p_prison-pr_ip);
sa.sin_len=sizeof (sa);
sa.sin_family = AF_INET;
error = in_pcbbind(inp, (struct sockaddr *)sa, p);
if (error) {
printf(in_pcbconnect error 1\n);
return (error);
}
}
[...snippage...]
And its failing this test in in_pcbbind():
in_pcbbind(inp, nam, p)
register struct inpcb *inp;
struct sockaddr *nam;
struct proc *p;
{
[...]
if (inp-inp_lport || inp-inp_laddr.s_addr != INADDR_ANY) {
printf(in_pcbbind error 4\n);
return (EINVAL);
}
[...]
I'm guessing right now that inp_lport in the pcb is getting set during the
first system call, and causing the subsequent ones to fail. I don't have
all the answers though, and I need to get some sleep... Hoping someone
who understands the pcb functions can point out exactly what the error is
in here -- this is the first time i've ever looked at them...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: jail bug with ircd-hybrid in_pcbconnect()?
On Mon, 18 Mar 2002, Terry Lambert wrote: Lamont Granquist wrote: On Mon, 18 Mar 2002, Poul-Henning Kamp wrote: All I can say is that I have had hell with that code and jail, and you might be right that some cleanup after the first call is missing. You're probably also the closest person to fix it at this point... Alright, I'll keep digging. My guess is that on the first call we've got: inp-inp_laddr.s_addr == INADDR_ANY inp-inp_lport == 0 And that after the first call we're supposed to have laddr = jail IP and lport = emphemeral, but for some reason laddr isn't getting set, so on the 2nd call we've got laddr = INADDR_ANY and lport = emphemeral and that in_pcbbind() pukes on that. There's a bug in the hash code that treats a lookup of a local bind as if it were in the INADDR_ANY domain, instead of in a per IP address domain, when you are using a wildcard port. The easy workaround is to bind to the local address, instead of INADDR_ANY. My brief reading of what the code is doing suggests that it is trying to do this for you when you're in a jail, but its failing to do it right. You can trigger the bug on outbound connections by using a wildcard port with a specified local IP address; it basically ignores the local IP address contribution in the has compare, and assigns outbound ports sequentially out of a single port space, instead of having per IP address port spaces. I don't think this bug is causing the problem that I'm seeing. I'm going to have to dig in and think about it a bit more tonight... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
(PATCH) Re: jail bug with ircd-hybrid in_pcbconnect()?
this fixes the problem, i'm not familiar enough with pcbs to know if this
opens up a security hole in the jail though...
--- in_pcb.c.oldMon Mar 18 23:57:57 2002
+++ in_pcb.cTue Mar 19 00:04:33 2002
@@ -500,7 +500,8 @@
struct sockaddr_in sa;
int error;
- if (inp-inp_laddr.s_addr == INADDR_ANY p-p_prison != NULL) {
+ if (inp-inp_laddr.s_addr == INADDR_ANY inp-inp_lport == 0
+ p-p_prison != NULL) {
bzero(sa, sizeof (sa));
sa.sin_addr.s_addr = htonl(p-p_prison-pr_ip);
sa.sin_len=sizeof (sa);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Repost - f_type value in statfs structure
On Sun, 23 Dec 2001, Chad David wrote: On Sat, Dec 22, 2001 at 11:11:12PM +, Wayne Pascoe wrote: Chad David [EMAIL PROTECTED] writes: The issue that I am having is detecting valid filesystems to do further checks on. I am only interested in checking local filesystems such as UFS. Check for the MNT_LOCAL flag in f_flags. -- code example snipped -- Thanks for that. I've tried it and the problem with it is that it reports things like procfs and devfs as being local. The only things that don't appear local are things like nfs mounts. I guess I need a way to check only filesystems mounted off of disks. Is there any way of doing this ? They are local :). Local means that the fs originates on the local machine. I think you should be able to call getvfsbyname() and check the flags in the resulting vfsconf struct for VFCF_SYNTHETIC, but I'm not sure how reliable that is. I'm pretty sure devfs is ok, but procfs might not be? try vn_isdisk(vp, error) where vp is the vnode pointer to the block device? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
The care and feeding of Vnodes?
So, yesterday I was playing around with the VFS code and trying to figure out how to get a 'stub' of a filesystem that I could mount and unmount. To do so I need to implement vfs_root() which requires returning a vnode for the root of the filesystem. So, I just called getnewvnode(), passing it some 'stubby' vfsops that would just printf() whenever they were called. That way I thought I could figure out what was getting done to the vnode. I didn't do any other initialization to the vnode. So, I mounted the filesystem this way, and tried to unmount it and I got a couple of vnops further into getting the filesystem to unmount. However, a few minutes later my laptop locked up, and upon rebooting I got softupdate inconsistencies and filesystem corruption. How did I manage to hose my system this badly just playing around with one vnode? And what should I do in order to pass back this kind of fake root vnode that isn't backed up by any actual filestore? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: The care and feeding of Vnodes?
On Sat, 22 Dec 2001, Alfred Perlstein wrote:
* Lamont Granquist [EMAIL PROTECTED] [011222 16:06] wrote:
So, yesterday I was playing around with the VFS code and trying to figure
out how to get a 'stub' of a filesystem that I could mount and unmount.
To do so I need to implement vfs_root() which requires returning a vnode
for the root of the filesystem. So, I just called getnewvnode(), passing
it some 'stubby' vfsops that would just printf() whenever they were
called. That way I thought I could figure out what was getting done to
the vnode. I didn't do any other initialization to the vnode.
So, I mounted the filesystem this way, and tried to unmount it and I got a
couple of vnops further into getting the filesystem to unmount. However,
a few minutes later my laptop locked up, and upon rebooting I got
softupdate inconsistencies and filesystem corruption. How did I manage to
hose my system this badly just playing around with one vnode? And what
should I do in order to pass back this kind of fake root vnode that
isn't backed up by any actual filestore?
Most likely your misbehaving VOPs caused corruption of other data.
that's a little odd, because the VOPs were just the vfs_default.c ones
with printf()s thrown in them
Without source to your failed experiment it will be hard to determine
what the problem is.
'k, here you go:
/* lcgfs_vfsops.c */
#include sys/param.h
#include sys/kernel.h
#include sys/systm.h
#include sys/vnode.h
#include sys/mount.h
vop_t **lcgfs_vnodeop_p; /* XXX: needs to go in header file */
static int lcgfs_statfs __P((struct mount *, struct statfs *, struct proc *));
static int lcgfs_mount __P((struct mount *, char *, caddr_t, struct nameidata *,
struct proc *));
static int lcgfs_root __P((struct mount *mp, struct vnode **vpp));
static int lcgfs_mount_stub __P((struct mount *mp, char *path, caddr_t data,
struct nameidata *ndp, struct proc *p));
static int lcgfs_start_stub __P((struct mount *mp, int flags, struct proc *p));
static int lcgfs_unmount_stub __P((struct mount *mp, int mntflags,
struct proc *p));
static int lcgfs_root_stub __P((struct mount *mp, struct vnode **vpp));
static int lcgfs_quotactl_stub __P((struct mount *mp, int cmds, uid_t uid,
caddr_t arg, struct proc *p));
static int lcgfs_statfs_stub __P((struct mount *mp, struct statfs *sbp,
struct proc *p));
static int lcgfs_sync_stub __P((struct mount *mp, int waitfor,
struct ucred *cred, struct proc *p));
static int lcgfs_vget_stub __P((struct mount *mp, ino_t ino,
struct vnode **vpp));
static int lcgfs_fhtovp_stub __P((struct mount *mp, struct fid *fhp,
struct vnode **vpp));
static int lcgfs_checkexp_stub __P((struct mount *mp, struct sockaddr *nam,
int *extflagsp, struct ucred **credanonp));
static int lcgfs_vptofh_stub __P((struct vnode *vp, struct fid *fhp));
static int lcgfs_init_stub __P((struct vfsconf *));
static int lcgfs_uninit_stub __P((struct vfsconf *));
static int lcgfs_extattrctl_stub __P((struct mount *mp, int cmd,
const char *attrname, caddr_t arg, struct proc *p));
static int
lcgfs_statfs(mp, sbp, p)
struct mount *mp;
struct statfs *sbp;
struct proc *p;
{
sbp-f_bsize = 512;
sbp-f_iosize = 512;
sbp-f_blocks = 1024;
sbp-f_bfree = 512;
sbp-f_bavail = 512;
sbp-f_files = 11;
sbp-f_ffree = 22;
if (sbp != mp-mnt_stat) {
sbp-f_type = mp-mnt_vfc-vfc_typenum;
bcopy((caddr_t)mp-mnt_stat.f_mntonname,
(caddr_t)sbp-f_mntonname[0], MNAMELEN);
bcopy((caddr_t)mp-mnt_stat.f_mntfromname,
(caddr_t)sbp-f_mntfromname[0], MNAMELEN);
}
strncpy(sbp-f_fstypename, mp-mnt_vfc-vfc_name, MFSNAMELEN);
return (0);
}
static int
lcgfs_mount(mp, path, data, ndp, p)
struct mount *mp;
char *path;
caddr_t data;
struct nameidata *ndp;
struct proc *p;
{
size_t size;
(void) copyinstr(path, mp-mnt_stat.f_mntonname, MNAMELEN - 1, size);
bzero(mp-mnt_stat.f_mntonname + size, MNAMELEN - size);
strcpy(mp-mnt_stat.f_mntfromname, lcgfs);
bzero(mp-mnt_stat.f_mntfromname + size, MNAMELEN - 5);
/* (void) copyinstr(args.fspec, mp-mnt_stat.f_mntfromname, MNAMELEN - 1,
size);
bzero(mp-mnt_stat.f_mntfromname + size, MNAMELEN - size); */
(void) lcgfs_statfs(mp, mp-mnt_stat, p);
return(0);
}
int
lcgfs_mount_stub (mp, path, data, ndp, p)
struct mount *mp;
char *path;
caddr_t data;
struct nameidata *ndp;
struct proc *p;
{
printf(lcgfs_mount_stub\n);
return (0);
}
int
lcgfs_unmount_stub (mp, mntflags, p)
struct mount *mp;
int mntflags;
struct proc *p;
{
printf(lcgfs_unmount_stub\n);
return (0);
}
int
lcgfs_root
What a FBSD FS needs to do?
Can anyone give a brief overview (or point to one) of what a FS in FreeBSD needs to do to interact with the rest of the OS? The general picture I've got is of some code which interacts with the VFS layer above it and the block I/O layer down below it. It is this correct? And what are the APIs in those layers? (and how does the FS interact with the VM?) (I actually plan on sitting down and reading the FFS sources at some point in the near future and seeing if I can learn that way, but any help would be appreciated...) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: What a FBSD FS needs to do?
On Mon, 17 Dec 2001, Terry Lambert wrote: [...snippage all over...] wow! thanks! that was much more than i'd hoped for! unfortunately i'm very much a beginner to kernel hacking, so don't expect any ported filesystems out of me in the near future... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tangent for discussion: FreeBSD performs worse that Linux
I think what would be cool would be to have a RELENG_4_4_BUGFIX tree which was for bugfixes, but was feature frozen. It shouldn't get new features like dirprefs (otherwise its difficult to differentiate it from -STABLE itself) but it should get bugfixes. That way FreeBSD would wind up with some extremely stable and feature frozen code. Unfortunately, I'm not qualified to volunteer to engineer such a branching scheme... On Sun, 9 Dec 2001, D J Hawkey Jr wrote: On Dec 09, at 12:11 AM, Matthew Dillon wrote: In anycase, your patches look fine. In fact, you not only applied my fixes you also applied a fix in the delayed-ack check that was made (by someone else) some time after 4.2Rel -- the callout_pending() check in DELAY_ACK() fixed a serious bug in prior releases all by itself. Kudos! I know it's been discussed before, but if this is considered a serious bug, shouldn't it also be applied to supported-but-not-stable versions? RELENG_(release - 1) seems to be the target of backported security fixes, and I have no problem with that - a line has to be drawn somewhere - but I (and likely many others) would love to see things such as this (things that aren't security focused) be made to RELENG_(release - 1). If I hadn't caught the DELACK thread on this list, I never would have known that TCP/IP throughput could be fixed/enhanced so easily - for me, that is, I only applied a patch, but pro'lly not for Matt. Another candidate for this sort of thing I'd like to see backported to RELENG_(release - 1) would be DIRPREFS, but that might be asking too much; I don't know how many modules were hacked for that. I took it upon myself to add ICH sound support to my 4.2REL kernel and another 4.3REL kernel, based on the original patches submitted. This is an example of what pro'lly could be omitted from RELENG_(release - 1), but a FreeBSD.org sanctioned facility where the likes of us unsupported- or-supported-but-not-stable hackers could upload/submit patches would be a nice thing. Just my two-cents' worth of thoguht food. Dave -- __ __ \__ \D. J. HAWKEY JR. / __/ \/\ [EMAIL PROTECTED]/\/ http://www.visi.com/~hawkeyd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Can TCP changes be put in RELENG_4?
On Thu, 6 Dec 2001, Leo Bicknell wrote: On Wed, Dec 05, 2001 at 10:15:30PM -0800, Terry Lambert wrote: and ordinary user will find FreeBSD is slower, could we let user to select which kernel to install at installing time? It's a possibility that I've considered, given that sysinstall had a hard time supporting installing FreeBSD from a single CDROM image to support both developers and the end product with a single golden system image. The problem with doing this is that it sort of grates against the idea of a GENERIC entirely. The problem with GENERIC is it is the lowest common denominator. While it's really cool we can still boot on a 386 with 4 meg of RAM, making the compromises to make that happen is not terribly useful. An alternative solution that i haven't read anyone suggest on this thread is simply to improve man tuning(7) and make people more aware of it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Can TCP changes be put in RELENG_4?
On Thu, 6 Dec 2001, Andreas Klemm wrote: On Thu, Dec 06, 2001 at 09:26:40AM -0800, Lamont Granquist wrote: An alternative solution that i haven't read anyone suggest on this thread is simply to improve man tuning(7) and make people more aware of it. Could (should ???) be part of the installation process, accessible as menue or submenue ??? Since it contains useful hints how to plan a useful filesystem layout. yeah, i really wish the installer had some fast-fsck newfs hints... (at least i have an excuse for not offering any code, though, as i just started a new job...) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Can TCP changes be put in RELENG_4?
FWIW, I'd vote for MFSing the TCP changes in -STABLE to RELENG_4_4. As it stands right now 4.4 is kinda broken. On Wed, 5 Dec 2001, Mike Barcroft wrote: Jim Durham [EMAIL PROTECTED] writes: Duh... right. OGS..(Old Guy Syndrome). I actually just did a cvsup to RELENG_4_4 and it didn't have the fixes. I guess I'll rephrase my question... Can we have the patches in REGENG_4_4?. RELENG_4_4 is for security fixes only. Consider using -STABLE if you require additional improvements. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Can TCP changes be put in RELENG_4?
On Wed, 5 Dec 2001, Leo Bicknell wrote: On Wed, Dec 05, 2001 at 03:12:29PM -0800, Crist J . Clark wrote: 4.5-RELEASE is only a month and a half away. By the time this while passes, we'll be there. If people have lived this long with the bugs, they can last until late January. I find it hard to argue with that. Same here. I thought 4.5 was further off than that... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Patch #3 (TCP / Linux / Performance)
On Sun, 2 Dec 2001, Matthew Dillon wrote: Throughput 47.2446 MB/sec (NB=59.0558 MB/sec 472.446 MBit/sec) 20 procs It seems to max-out at around 75,000 packets per second (input + output). I doubt these results could be duplicated on anything but a DELL2550. It dedicates an entire internal 64 bit 66MHz PCI bus just to the on-board gigabit ethernet. What is the remaining bottleneck in these tests? CPU? Interrupts? What would you need to do to get that closer to the theoretical limit (something around 920 Mbs for GigE IIRC)? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Patch #3 (TCP / Linux / Performance)
On Sun, 2 Dec 2001, Matthew Dillon wrote: This is connecting to inetd running a dd if=/dev/zero bs=32k on a machine with the rfc sysctl's turned on and 262144 byte send and receive buffers, without jumbo frames (my gigE switch doesn't support them :-( ). nice, 950 Mbs which should be the theoretical maximum. what kind of CPUs do you have in there, and do you know how hard they were working? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
detecting linux emulation in rtld.c?
can anyone suggest a method of determining inside libexec/rtld-elf/rtld.c if a binary being run is native or linux emulation? i'd like to be able to write code which basically does: if (IsNativeCode()) PreloadSomeLibraries() any suggestions? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: /etc/ld.so.preload?
Sorry, that one isn't backwards compatible with the present version of
the hints file. This one behaves nicer.
On Tue, 30 Oct 2001, Lamont Granquist wrote:
Well, here's a short patch to add the necessarily functionality to
/var/run/ld-elf.so.hints and /usr/libexec/ld-elf.so.1. If this is
acceptable, /sbin/ldconfig would need to be patched.
Looks like the major bug is that if you preload libraries globally you
break linux binary compatibility.
On Tue, 30 Oct 2001, Lamont Granquist wrote:
Is there anything in FreeBSD that gives this functionality? My reading of
src/libexec/rtld-elf/rtld.c in both -stable and -current seems to indicate
that there isn't any such functionality (i need the global functionality
that LD_PRELOAD doesn't give me). I'd be willing to write a patch for it,
but I'd need some guidance on what would be a proper way to fix it.
I'm thinking of a patch to ldconfig to get /etc/ld.so.preload into the
hints file and then to hack gethints() in rtld.c to take an argument
indicating which path you want to return.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
--- include/elf-hints.h~Tue Oct 30 18:29:57 2001
+++ include/elf-hints.h Tue Oct 30 18:31:47 2001
@@ -40,7 +40,10 @@
u_int32_t dirlist;/* Offset of directory list in
string table */
u_int32_t dirlistlen; /* strlen(dirlist) */
- u_int32_t spare[26]; /* Room for expansion */
+ u_int32_t preloadlist;/* Offset of preload list in
+ string table */
+ u_int32_t preloadlistlen; /* strlen(preloadlist) */
+ u_int32_t spare[24]; /* Room for expansion */
};
#define ELFHINTS_MAGIC 0x746e6845
--- libexec/rtld-elf/rtld.c~Tue Oct 30 18:28:00 2001
+++ libexec/rtld-elf/rtld.c Wed Oct 31 00:55:05 2001
@@ -52,8 +52,10 @@
#include debug.h
#include rtld.h
-#define END_SYM_end
-#define PATH_RTLD /usr/libexec/ld-elf.so.1
+#define END_SYM_end
+#define PATH_RTLD /usr/libexec/ld-elf.so.1
+#define HINT_LIBRARY_PATH 0x01
+#define HINT_PRELOAD 0x02
/* Types. */
typedef void (*func_ptr_type)();
@@ -80,7 +82,7 @@
static void errmsg_restore(char *);
static char *errmsg_save(void);
static char *find_library(const char *, const Obj_Entry *);
-static const char *gethints(void);
+static char *gethints(int);
static void init_dag(Obj_Entry *);
static void init_dag1(Obj_Entry *root, Obj_Entry *obj, DoneList *);
static void init_rtld(caddr_t);
@@ -91,7 +93,7 @@
static void linkmap_add(Obj_Entry *);
static void linkmap_delete(Obj_Entry *);
static int load_needed_objects(Obj_Entry *);
-static int load_preload_objects(void);
+static int load_preload_objects(char *);
static Obj_Entry *load_object(char *);
static void lock_check(void);
static Obj_Entry *obj_from_addr(const void *);
@@ -359,7 +361,9 @@
sym_zero.st_shndx = SHN_ABS;
dbg(loading LD_PRELOAD libraries);
-if (load_preload_objects() == -1)
+if (load_preload_objects(ld_preload) == -1)
+ die();
+if (load_preload_objects(gethints(HINT_PRELOAD)) == -1)
die();
preload_tail = obj_tail;
@@ -805,7 +809,7 @@
if ((refobj != NULL
(pathname = search_library_path(name, refobj-rpath)) != NULL) ||
(pathname = search_library_path(name, ld_library_path)) != NULL ||
- (pathname = search_library_path(name, gethints())) != NULL ||
+ (pathname = search_library_path(name, gethints(HINT_LIBRARY_PATH))) != NULL ||
(pathname = search_library_path(name, STANDARD_LIBRARY_PATH)) != NULL)
return pathname;
@@ -873,38 +877,54 @@
* necessary. Returns NULL if there are problems with the hints file,
* or if the search path there is empty.
*/
-static const char *
-gethints(void)
+static char *
+gethints(int hintflag)
{
-static char *hints;
+static char *preload;
+static char *library_path;
-if (hints == NULL) {
+if ((library_path == NULL) || (preload == NULL)) {
int fd;
struct elfhints_hdr hdr;
char *p;
/* Keep from trying again in case the hints file is bad. */
- hints = ;
+ library_path = ;
+ preload = ;
if ((fd = open(_PATH_ELF_HINTS, O_RDONLY)) == -1)
return NULL;
if (read(fd, hdr, sizeof hdr) != sizeof hdr ||
hdr.magic != ELFHINTS_MAGIC ||
hdr.version != 1) {
- close(fd);
- return NULL;
+ goto cleanup;
}
p = xmalloc(hdr.dirlistlen + 1);
if (lseek(fd, hdr.strtab + hdr.dirlist, SEEK_SET) == -1 ||
read(fd, p, hdr.dirlistlen + 1) != hdr.dirlistlen + 1) {
free(p
Re: Unix Philosophers Please!
On Wed, 31 Oct 2001, Stephen Montgomery-Smith wrote: Nicpon, John wrote: Please specifically define where data goes that is sent to /dev/null Answer 1. Data is not like energy. There is no conservation of data law. So the data simply disappears. Doesn't thermodynamics second law actually imply that data has to disappear and that with the heat death of the universe data will be at a minimum? For meaningful data to exist there needs to be order, while the 2nd law requires that systems evolve to less ordered states. The only uncertainty about this that I've got is that random systems can actually be very dense with data. Think about a compressed and encrypted file, which should be indistinguishable from /dev/random output. I guess the difference between those two is that there is only a single state which validly represents the comprssed and encrypted file. On the other hand there may be many states which represent the valid output of /dev/random (of course you only obtain one of these states). Since there are more states for /dev/random there is more entropy (and actually the compressed file having only one valid state would have minimal entropy). Did I get that right? My thermodynamics and info theory are a little rusty... Contribute to the Heat Death of the Universe! pipe everything to /dev/null! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
/etc/ld.so.preload?
Is there anything in FreeBSD that gives this functionality? My reading of src/libexec/rtld-elf/rtld.c in both -stable and -current seems to indicate that there isn't any such functionality (i need the global functionality that LD_PRELOAD doesn't give me). I'd be willing to write a patch for it, but I'd need some guidance on what would be a proper way to fix it. I'm thinking of a patch to ldconfig to get /etc/ld.so.preload into the hints file and then to hack gethints() in rtld.c to take an argument indicating which path you want to return. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: /etc/ld.so.preload?
Well, here's a short patch to add the necessarily functionality to
/var/run/ld-elf.so.hints and /usr/libexec/ld-elf.so.1. If this is
acceptable, /sbin/ldconfig would need to be patched.
Looks like the major bug is that if you preload libraries globally you
break linux binary compatibility.
On Tue, 30 Oct 2001, Lamont Granquist wrote:
Is there anything in FreeBSD that gives this functionality? My reading of
src/libexec/rtld-elf/rtld.c in both -stable and -current seems to indicate
that there isn't any such functionality (i need the global functionality
that LD_PRELOAD doesn't give me). I'd be willing to write a patch for it,
but I'd need some guidance on what would be a proper way to fix it.
I'm thinking of a patch to ldconfig to get /etc/ld.so.preload into the
hints file and then to hack gethints() in rtld.c to take an argument
indicating which path you want to return.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
--- include/elf-hints.h~Tue Oct 30 18:29:57 2001
+++ include/elf-hints.h Tue Oct 30 18:31:47 2001
@@ -40,7 +40,10 @@
u_int32_t dirlist;/* Offset of directory list in
string table */
u_int32_t dirlistlen; /* strlen(dirlist) */
- u_int32_t spare[26]; /* Room for expansion */
+ u_int32_t preloadlist;/* Offset of preload list in
+ string table */
+ u_int32_t preloadlistlen; /* strlen(preloadlist) */
+ u_int32_t spare[24]; /* Room for expansion */
};
#define ELFHINTS_MAGIC 0x746e6845
--- libexec/rtld-elf/rtld.c~Tue Oct 30 18:28:00 2001
+++ libexec/rtld-elf/rtld.c Tue Oct 30 21:06:39 2001
@@ -52,8 +52,10 @@
#include debug.h
#include rtld.h
-#define END_SYM_end
-#define PATH_RTLD /usr/libexec/ld-elf.so.1
+#define END_SYM_end
+#define PATH_RTLD /usr/libexec/ld-elf.so.1
+#define HINT_LIBRARY_PATH 0x01
+#define HINT_PRELOAD 0x02
/* Types. */
typedef void (*func_ptr_type)();
@@ -80,7 +82,7 @@
static void errmsg_restore(char *);
static char *errmsg_save(void);
static char *find_library(const char *, const Obj_Entry *);
-static const char *gethints(void);
+static char *gethints(int);
static void init_dag(Obj_Entry *);
static void init_dag1(Obj_Entry *root, Obj_Entry *obj, DoneList *);
static void init_rtld(caddr_t);
@@ -91,7 +93,7 @@
static void linkmap_add(Obj_Entry *);
static void linkmap_delete(Obj_Entry *);
static int load_needed_objects(Obj_Entry *);
-static int load_preload_objects(void);
+static int load_preload_objects(char *);
static Obj_Entry *load_object(char *);
static void lock_check(void);
static Obj_Entry *obj_from_addr(const void *);
@@ -359,7 +361,9 @@
sym_zero.st_shndx = SHN_ABS;
dbg(loading LD_PRELOAD libraries);
-if (load_preload_objects() == -1)
+if (load_preload_objects(ld_preload) == -1)
+ die();
+if (load_preload_objects(gethints(HINT_PRELOAD)) == -1)
die();
preload_tail = obj_tail;
@@ -805,7 +809,7 @@
if ((refobj != NULL
(pathname = search_library_path(name, refobj-rpath)) != NULL) ||
(pathname = search_library_path(name, ld_library_path)) != NULL ||
- (pathname = search_library_path(name, gethints())) != NULL ||
+ (pathname = search_library_path(name, gethints(HINT_LIBRARY_PATH))) != NULL ||
(pathname = search_library_path(name, STANDARD_LIBRARY_PATH)) != NULL)
return pathname;
@@ -873,18 +877,20 @@
* necessary. Returns NULL if there are problems with the hints file,
* or if the search path there is empty.
*/
-static const char *
-gethints(void)
+static char *
+gethints(int hintflag)
{
-static char *hints;
+static char *preload;
+static char *library_path;
-if (hints == NULL) {
+if ((library_path == NULL) || (preload == NULL)) {
int fd;
struct elfhints_hdr hdr;
char *p;
/* Keep from trying again in case the hints file is bad. */
- hints = ;
+ library_path = ;
+ preload = ;
if ((fd = open(_PATH_ELF_HINTS, O_RDONLY)) == -1)
return NULL;
@@ -901,10 +907,25 @@
close(fd);
return NULL;
}
- hints = p;
+ library_path = p;
+ p = xmalloc(hdr.preloadlistlen + 1);
+ if (lseek(fd, hdr.strtab + hdr.preloadlist, SEEK_SET) == -1 ||
+ read(fd, p, hdr.preloadlistlen + 1) != hdr.preloadlistlen + 1) {
+ free(p);
+ close(fd);
+ return NULL;
+ }
+ preload = p;
close(fd);
}
-return hints[0] != '\0' ? hints : NULL;
+switch (hintflag) {
+ case HINT_LIBRARY_PATH:
+ return library_path[0
Re: MT-Safe wrapper around memcpy()?
On Mon, 29 Oct 2001, Alfred Perlstein wrote: * Lamont Granquist [EMAIL PROTECTED] [011029 00:43] wrote: I'm trying to figure out the best way to write a wrapper around memcpy() which can call fprintf() without winding up getting into a recursive loop. The problem is that fprintf() will call memcpy() and around and around we go. I can use a global variable to prevent this, but that usage isn't thread safe. I can make it thread safe by using pthread keys, but then i have to link in libc_r, and for non-pthreaded programs i don't want to do that. Anyone have any suggestions? Right now I'm almost thinking that I just need to directly patch libc and libc_r. It might be an ugly patch though, and I'd rather not have this patch mandate recompiling all of libc. Where do you see mem* calling printf? that's in my wrapper around memcpy. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: MT-Safe wrapper around memcpy()?
On Mon, 29 Oct 2001, Alfred Perlstein wrote: * Alfred Perlstein [EMAIL PROTECTED] [011029 00:53] wrote: * Lamont Granquist [EMAIL PROTECTED] [011029 00:43] wrote: I'm trying to figure out the best way to write a wrapper around memcpy() which can call fprintf() without winding up getting into a recursive loop. The problem is that fprintf() will call memcpy() and around and around we go. I can use a global variable to prevent this, but that usage isn't thread safe. I can make it thread safe by using pthread keys, but then i have to link in libc_r, and for non-pthreaded programs i don't want to do that. Anyone have any suggestions? Right now I'm almost thinking that I just need to directly patch libc and libc_r. It might be an ugly patch though, and I'd rather not have this patch mandate recompiling all of libc. Where do you see mem* calling printf? Uh, nevermind. :) Ok, what you want to do is use a nested flag in memcpy so you don't recurse, there's some code in libc that's conditionally compiled when compiling libc_r, _THREAD_SAFE or something is defined, once you find that then just simply use the global for non threaded programs and keys for threaded ones. you mean like localtime.c: #ifdef _THREAD_SAFE pthread_mutex_lock(lcl_mutex); #endif and such? problem is that i could do that if i was dropping it into libc itself, but as a single .so that i want to LD_PRELOAD, i need a run-time conditional rather than a precompiler conditional. i think i may be asking for a lot... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
MT-Safe wrapper around memcpy()?
I'm trying to figure out the best way to write a wrapper around memcpy() which can call fprintf() without winding up getting into a recursive loop. The problem is that fprintf() will call memcpy() and around and around we go. I can use a global variable to prevent this, but that usage isn't thread safe. I can make it thread safe by using pthread keys, but then i have to link in libc_r, and for non-pthreaded programs i don't want to do that. Anyone have any suggestions? Right now I'm almost thinking that I just need to directly patch libc and libc_r. It might be an ugly patch though, and I'd rather not have this patch mandate recompiling all of libc. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
