Re: Support for Tyan Thunder K8SR w/ Adaptec 7902 under AMD64
On Sat, Mar 19, 2005 at 02:56:17AM -0800, [EMAIL PROTECTED] wrote: Tyan board is fully supported in FreeBSD AMD64. Does anyone know off hand? I checked i386 and did not see anything directly stating 7902. Unfortunately, I do not have an AMD machine here at the moment, so I can't check the Kernel config file. Does anyone know off hand? Yes, the 7902 chip is supported by the ahd driver. I have a K8SR motherboard and scsi works just fine. You probably want to install a 5.4 snapshot or 5.4 release when its available. -- Steve ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Xen support
In all fairness I'd like to say that Nate put me in touch with someone to commit the work. At about the same time I discovered a rather annoying bug (since fixed), and I haven't followed back up. For those who would like to try it out I just submitted a sparse tree patch against the development branch (xeno-unstable.bk), that I believe will be committed shortly. It and a kernel can be found at: http://www.fsmware.com/xenofreebsd/5.3/050317/ You'll find some very basic instructions for booting a FreeBSD guest on xen one level up. To avoid premature enthusiasm I'd like to point out that FreeBSD is currently only supported as an unprivileged guest. DOM0 support is not that much work, it simply isn't a priority at the moment. -Kip -Original Message- From: Eric Masson [mailto:[EMAIL PROTECTED] Sent: Saturday, March 19, 2005 6:53 AM To: Mailing List FreeBSD Hackers Subject: Xen support Hello, Everybody here probably knows about Xen, the virtualization layer from Cambridge University (Uk) : http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ Is there any hope to see Kip Macy's work on Xen Support merged in the main tree anytime soon ? http://sourceforge.net/mailarchive/forum.php?thread_id=6793311forum_id=35600 Regards Éric Masson -- Subject: Re: procmail NK comment créer un filtre (...) Menu - Edition - Filtres de courrier - Nouveau. -+- G in: GNU - WISIWYSS (What I See Is What You Should See) -+- ___ 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]
passwd permissions
Hey, I'm using FreeBSD on various servers for many time now, and there is something that always bothered me. It is related to /etc/passwd and /etc/pwd.db permissions. I have custom (0640) permissions on these files. However, each time a user changes his/her password, the system will reset the password file permissions back to the original (rw r r). I'm not much of a programmer, but I tried to change passwd.c source to do a execl() at the end of the file (calling chmod). After trying it, the permissions were reset anyway, so I added a perror(execl) and it says permission denied. Should be because passwd dropped privileges at that part of the program. I've thought about a cron job to fix the permissions every X minutes, but I'd like a more clean option to this. Where in the system can I change the permission-reset behaviour ? This also happens, for example, with /usr/local/sbin/ (rwx rx x are my permissions) after I upgrade any port, it will be rwx rx rx , and /usr/local/www too. I've edited the mtree/ files as it sounded like a good lead, but the behaviour remains. What should I do ? Thanks. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: passwd permissions
On Sun, Mar 20, 2005 at 01:26:57PM -0600, H. S. wrote: I'm using FreeBSD on various servers for many time now, and there is something that always bothered me. It is related to /etc/passwd and /etc/pwd.db permissions. I have custom (0640) permissions on these files. However, each time a user changes his/her password, the system will reset the password file permissions back to the original (rw r r). I think these files would be rebuilt by the pwd_mkdb utility. You should be able to change it to rebuild the files with different permissions. See the PERM_INSECURE and PERM_SECURE constant pwd_mkdb.c. (I'm not really sure about the wisdom of making passwd and pwd.db have permissions 640, but I guess you know your system best.) David. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Causing a process switch to test a theory.
Greetings, I posted a similar message earlier, but I think I was too vague to solicit any kind of response. I'm also trying to stay relevant to the forum, but I can only offer the fact that I'm using FreeBSD as my OS of choice. If this is too far removed from being on topic, I apologize in advance and will take my questions elsewhere. I think I have found a possible bug in Apache's logging when using their reliable pipe feature, but I'd like to test it prior to submitting a bug report (or possibly a patch.) Of course I posted a message on the Apache development forum before posting here, but I have had no response from that group. My understanding of PIPE_BUF is that it is the largest amount of data the kernel will guarantee to be atomic when writing to a pipe. Thus if more than one process is writing to the same pipe, and more than PIPE_BUF bytes needs to be written, there is the chance of the data being interleaved due to a context switch during write(), or between multiple calls to write() in order to write all required data. I've been reading the Apache source code to try and determine if PIPE_BUF is taken into consideration while logging entries to a pipe. What appears to happen is that if a single log entry is more than 512 bytes, it is simply written to the the pipe without regard to PIPE_BUF. But there is a lot going on in Apache and I might very easily miss what's really happening somewhere else in the code. I'm pretty sure I can see what's going on and that the code needs to be fixed, but I don't want to go blowing my horn without some proof. What fstat seems to show me is that each child process (I'm running the 1.x branch of Apache) has the pipe open for writing, thus each child logs it's own entries instead of passing them to a single logging process (which could be used as some sort of serialization and control to prevent interleaving the log entries.) In this situation (each child logging it's own entries) it seems there is the possibility that a child could be preempted during it's call to write() when trying to write more than PIPE_BUF bytes of log data. What I'd like to do is create a test where I would be making requests to Apache that would cause log entries longer than PIPE_BUF in length, then be able to show the interleaving of log entries due to the PIPE_BUF limit being exceeded. The 2.x branch of Apache has an experimental features called BufferedLogs, that if used seems to protect the writing of the log entries with a mutex. However, it is not enabled by default and the normal logging does not use the mutex. I would have assumed the PIPE_BUF limit would not have been overlooked by the Apache developers, especially since they don't ignore log entires until they reach 8190 bytes (which is certainly longer than PIPE_BUF.) Basically it comes down to what happens when making this call: write(cls-log_fd, str, len); Under the conditions such that cls-log_fd is a pipe (inherited from the parent), len PIPE_BUF, and there are multiple child processes all logging entries with this code. Knowing if Apache could possibly write interleaved logs when writing to a pipe is critical to a program I'm developing which receives log entries from Apache via a pipe. Thank you, Matthew ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: passwd permissions
Hey, #define PERM_INSECURE (S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH) #define PERM_SECURE (S_IRUSR|S_IWUSR) Thanks, removing S_IROTH worked :-) While we're at it, what is the cause for the system changing permissions when I install a port ? (ie /usr/local/sbin and /usr/local/www) As I've said in my previous mail, changing the mtree/ files to reflect my desired permissions sounded logical, but either I failed some step or it isn't the way to go. On Sun, Mar 20, 2005 at 01:26:57PM -0600, H. S. wrote: I'm using FreeBSD on various servers for many time now, and there is something that always bothered me. It is related to /etc/passwd and /etc/pwd.db permissions. I have custom (0640) permissions on these files. However, each time a user changes his/her password, the system will reset the password file permissions back to the original (rw r r). I think these files would be rebuilt by the pwd_mkdb utility. You should be able to change it to rebuild the files with different permissions. See the PERM_INSECURE and PERM_SECURE constant pwd_mkdb.c. (I'm not really sure about the wisdom of making passwd and pwd.db have permissions 640, but I guess you know your system best.) David. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: passwd permissions
This may be partially related to the fact that I believe the system generates those files automatically from /etc/master.passwd. So if you change the perms on /etc/passwd, then when the system comes along and regenerates the files from /etc/master.passwd, it would change the permissions during that process I would think. I've never looked into the details of how it all happens (as far as master.passwd vs. passwd), but this might be something to check into, as it could relate to your situation. Ray At 01:26 PM 3/20/2005 -0600, H. S. wrote: | Hey, | | I'm using FreeBSD on various servers for many time now, and there is | something that always bothered me. It is related to /etc/passwd and | /etc/pwd.db permissions. | | I have custom (0640) permissions on these files. However, each time a user | changes his/her password, the system will reset the password file | permissions back to the original (rw r r). I'm not much of a programmer, | but I tried to change passwd.c source to do a execl() at the end of the | file (calling chmod). After trying it, the permissions were reset anyway, | so I added a perror(execl) and it says permission denied. Should be | because passwd dropped privileges at that part of the program. I've | thought about a cron job to fix the permissions every X minutes, but I'd | like a more clean option to this. | | Where in the system can I change the permission-reset behaviour ? This | also happens, for example, with /usr/local/sbin/ (rwx rx x are my | permissions) after I upgrade any port, it will be rwx rx rx , and | /usr/local/www too. | | I've edited the mtree/ files as it sounded like a good lead, but the | behaviour remains. | | What should I do ? | | Thanks. | | ___ | freebsd-hackers@freebsd.org mailing list | http://lists.freebsd.org/mailman/listinfo/freebsd-hackers | To unsubscribe, send any mail to [EMAIL PROTECTED] | | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Causing a process switch to test a theory.
If you post the section(s) of code in question, then you'll probably elicit some responses. PIPE_BUF is a POSIX defined minimum, so you might grep for sections of code that contain fpathconf(*, _PC_PIPE_BUF) to determine if the programmers took this into consideration. At least you'll be able to follow the logical flow of the program from fpathconf() forward. Further, if you do some fancy programming (like preempting a process unnaturally) to determine if there is an error in this particular aspect of Apache, then you'll also have to show that you have not inflicted the error too, which will probably be harder than what you set out to solve or figure out. Good luck, Zera Holladay ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Causing a process switch to test a theory.
In [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: I think I have found a possible bug in Apache's logging when using their reliable pipe feature, but I'd like to test it prior to submitting a bug report (or possibly a patch.) Of course I posted a message on the Apache development forum before posting here, but I have had no response from that group. And based on your description, I think I agree. My understanding of PIPE_BUF is that it is the largest amount of data the kernel will guarantee to be atomic when writing to a pipe. Thus if more than one process is writing to the same pipe, and more than PIPE_BUF bytes needs to be written, there is the chance of the data being interleaved due to a context switch during write(), or between multiple calls to write() in order to write all required data. Yes, that is exactly the POSIX semantic for PIPE_BUF. There are a lot of tricky details in there that are not fully obvious, and it's now been long enough (6 years) that I've forgotten the exact details. There are some weird interactions between O_NONBLOCK and PIPE_BUF, but it looks like some of them have been ironed out in recent versions of the standard. I've been reading the Apache source code to try and determine if PIPE_BUF is taken into consideration while logging entries to a pipe. What appears to happen is that if a single log entry is more than 512 bytes, it is simply written to the the pipe without regard to PIPE_BUF. Then there is definitely a risk of interleaving. This is basically a race condition -- if you're lucky the log reader can cope, but that depends greatly on the guts of the logger. In this situation (each child logging it's own entries) it seems there is the possibility that a child could be preempted during it's call to write() when trying to write more than PIPE_BUF bytes of log data. What I'd like to do is create a test where I would be making requests to Apache that would cause log entries longer than PIPE_BUF in length, then be able to show the interleaving of log entries due to the PIPE_BUF limit being exceeded. I would guess that the easiest way to run into this is to cause lots of processes to write larger blocks to the same pipe (are they all really writing to the exact same pipe? If not, no problem!) at the same time. An SMP box might be able to tickle this one better. Under the conditions such that cls-log_fd is a pipe (inherited from the parent), len PIPE_BUF, and there are multiple child processes all logging entries with this code. Assuming they're all writing to the same log_fd, then you might have a problem. Knowing if Apache could possibly write interleaved logs when writing to a pipe is critical to a program I'm developing which receives log entries from Apache via a pipe. That's another layer of indirection, though. If all of the children have separate pipes to the parent, and then the parent logs to your program, all should be fine. But at the kernel level, yes, writes longer than PIPE_BUF might get interleaved. The longer the write, the higher the probability, so for your test, if you can generate, say, 10K writes over and over, you can probably trip it. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8 / 37N 20' 14.9 Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
