kernel programming
where's a good place for kernel programming documentation ? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ABV.BG автоматичен отговор
i'm not sure i understnad that language ? if you tell me which one it is I could use googles convertor --neuro On Wed, 20 Apr 2005 freebsd-hackers@freebsd.org wrote: blagodarq za izpratenoto ot Vas pismo nai skoro shte vi otgovorq!! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel programming
where's a good place for kernel programming documentation ? In no particular order: 1. The FreeBSD Developer's Handbook. 2. The FreeBSD Architecture Handbook. 3. The book 'The Design and Implementation of the FreeBSD Operating System', by Kirk McKusick and George Neville-Neil. 3. The section 9 manual pages. 4. The source code :). You may want to browse: http://www.freebsd.org/docs.html -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel programming
yeah thanks for that, i figured the code was a good start. Now that I know the docs i know where to go, cheers for that --neuro On Wed, 20 Apr 2005, Joseph Koshy wrote: where's a good place for kernel programming documentation ? In no particular order: 1. The FreeBSD Developer's Handbook. 2. The FreeBSD Architecture Handbook. 3. The book 'The Design and Implementation of the FreeBSD Operating System', by Kirk McKusick and George Neville-Neil. 3. The section 9 manual pages. 4. The source code :). You may want to browse: http://www.freebsd.org/docs.html -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
transparent squid proxy + bridge
Hi there,
Recently I tried to make a transparent web proxy on a machine
that run in bridging mode. At last, I decided to make a patch.
Here it is for those who want to do the same.
One interface should be given an IP address so squid may do
a requests. Squid listens on 127.0.0.1:8080.
I am using pf firewall, with this redirection rule:
rdr on $int proto tcp from any to any port 80 - (lo0) port 8080
This is what the patch does:
static void ether_input()
{
...
if (packet_is_IP_packet pf_enabled mbuf_copy = copy_the_mbuf) {
strip_ethernet_headers;
run_the_firewall;
if (packet_redirected_to_127.0.0.1)
bypass_the_bridge
free_the_mbuf_copy;
}
...
}
The patch is small, so I include it inline.
Tested on 5.4
if_ethersubr.c.patch
Description: Binary data
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: PXEBOOT/TFTPBOOT + big MD_ROOT problem
Objet : Re: PXEBOOT/TFTPBOOT + big MD_ROOT problem Hi, I'm trying to make very big MD_ROOT (300MB) sent using PXEBOOT+TFTPBOOT. No NFS. It's a sort of diskless machine with all the system on ram. There is a problem when the preloaded image is ~32MB. Kernel loads but it does not seem to find the files. It seems as if only part of the image is really there. With a small image (~32MB), no probleme. I use the same image, off course, same init etc... just more data for my application in the big image case. ... Am I missing something obvious? I assume you saw this in the tftpd manual page? BUGS Files larger than 33488896 octets (65535 blocks) cannot be transferred without client and server supporting blocksize negotiation (RFC1783). Many tftp clients will not transfer files over 1678 octets (32767 blocks). -DG Yes. Saw it. My tftp client and pxe+tftp under linux works ok. The tftp client under FreeBSD seems to work fine (1,5GB tranfered, md5sum checked, no pb). BUT, maybe the tftp client in the FreeBSD pxeboot has a problem. I am actually trying to make the mfsroot go through NFS. If that works, it will indicate the FreeBSD pxeboot has indeed this problem with TFTP. Emmanuel. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PXEBOOT/TFTPBOOT + big MD_ROOT problem
Marc Olzheim wrote: On Tue, Apr 19, 2005 at 09:52:07AM +0200, Emmanuel Chriqui wrote: Hi, I'm trying to make very big MD_ROOT (300MB) sent using PXEBOOT+TFTPBOOT. No NFS. Any reasons for not using NFS ? I use i386/5.4RC2/TFTPD/PXEBOOT+TFTPBOOT . (same pb with a 5.3). Am I missing something obvious? I'm not sure. tftp itself is able to handle 32MB+ files, but maybe the loader isn't. A workaround, no using NFS, could be to tftp a second filesystem image on boot and mount that from the root filesystem. Marc I assume that the PXE clients are diskless clients. If so, do they have enough memory to handle this extremely large image? As for tfpt, it uses UDP. UDP is usually used for transfer small datagrams, for instance DNS replies. It is also said to be an unreliable protocol. The client should repeat the request when no data receives. I doubt this solution is reliable and flexible enough. My idea for a workaround is creating a ramdisk from a small boot image, and transfer the less necessary userland binaries from the boot server to the ramdisk using normal ftp connection. Cheers, Gábor Kövesdán ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
sshd dieing? after applying FreeBSD-SA-03:12.openssh
On Wed, 17 Sep 2003 00:02:33 +0100 Steven Hartland asked this question but no answer was posted. The trouble is likely no client reverse DNS either because it is missing or slow. Adding the client to /etc/hosts on the server seems at first to do nothing but after a minute or so it stops hanging and asks for a password. Could be a coincidence though. To recap: $ ssh -v [EMAIL PROTECTED] OpenSSH_3.4p1+CAN-2004-0175, SSH protocols 1.5/2.0, OpenSSL 0x0090609f ... debug1: Remote protocol version 1.99, remote software version OpenSSH_3.6.1p1 FreeBSD-20030423 debug1: match: OpenSSH_3.6.1p1 FreeBSD-20030423 pat OpenSSH* Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.4p1+CAN-2004-0175 ... debug1: got SSH2_MSG_SERVICE_ACCEPT ---Here the client hangs until timeout. To debug: kill the server process and run # sshd -ddde ... debug3: Trying to reverse map address ... ---Here the server hangs until timeout. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PXEBOOT/TFTPBOOT + big MD_ROOT problem
Hi, I'm trying to make very big MD_ROOT (300MB) sent using PXEBOOT+TFTPBOOT. No NFS. It's a sort of diskless machine with all the system on ram. There is a problem when the preloaded image is ~32MB. Kernel loads but it does not seem to find the files. It seems as if only part of the image is really there. With a small image (~32MB), no probleme. I use the same image, off course, same init etc... just more data for my application in the big image case. ... Am I missing something obvious? I assume you saw this in the tftpd manual page? BUGS Files larger than 33488896 octets (65535 blocks) cannot be transferred without client and server supporting blocksize negotiation (RFC1783). Many tftp clients will not transfer files over 1678 octets (32767 blocks). -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 TeraSolutions, Inc. - http://www.terasolutions.com - (888) 346 7175 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Configuration differences for jails
Hi, I am now trying to use jail in FreeBSD. I have read the jail(8) man page and some others documents for setting up jails. But I'm a little confused about the procedure and configurations for setting up jails. As known to all, jail can be used for two purposes, i.e. jailing a single application or acting as a virtual host. What i want to know is the concrete configuration (procedure) difference between the two types use of jails. Is there a SMALLEST set of configuration necessary for setting up a jail? If so, what is it? Another question, is there any way to detect the share of files between multiple jails automatically? BTW, what is the meaning of IMHO? :) It appears very frequently in the mail list. Sorry for my bad english. Any reply is appreciated! Jas _ MSN Messenger: http://messenger.msn.com/cn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PXEBOOT/TFTPBOOT + big MD_ROOT problem
On Tue, Apr 19, 2005 at 04:18:17PM -0700, David G. Lawrence wrote: I assume you saw this in the tftpd manual page? BUGS Files larger than 33488896 octets (65535 blocks) cannot be transferred without client and server supporting blocksize negotiation (RFC1783). Many tftp clients will not transfer files over 1678 octets (32767 blocks). There is a PR open with a patch to fix this: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/67550 -- Francois Tigeot ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sshd dieing? after applying FreeBSD-SA-03:12.openssh
On Tue, 19 Apr 2005, Devon Sean McCullough wrote: On Wed, 17 Sep 2003 00:02:33 +0100 Steven Hartland asked this question but no answer was posted. The trouble is likely no client reverse DNS either because it is missing or slow. Adding the client to /etc/hosts on the server seems at first to do nothing but after a minute or so it stops hanging and asks for a password. Could be a coincidence though. To recap: $ ssh -v [EMAIL PROTECTED] OpenSSH_3.4p1+CAN-2004-0175, SSH protocols 1.5/2.0, OpenSSL 0x0090609f debug1: Remote protocol version 1.99, remote software version OpenSSH_3.6.1p1 FreeBSD-20030423 debug1: match: OpenSSH_3.6.1p1 FreeBSD-20030423 pat OpenSSH* Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.4p1+CAN-2004-0175 debug1: got SSH2_MSG_SERVICE_ACCEPT ---Here the client hangs until timeout. To debug: kill the server process and run # sshd -ddde debug3: Trying to reverse map address ... ---Here the server hangs until timeout. Dude, that was 2 years ago in 2003 the year now is 2005 and the current date is 'Wed Apr 20 12:32:31 UTC 2005' so umm, am I living in the future or are you dwelling on the past ???. -- ( When in doubt, use brute force. -- Ken Thompson 1998 ) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sshd dieing? after applying FreeBSD-SA-03:12.openssh
Date: Wed, 20 Apr 2005 08:33:36 -0400 (EDT) From: c0ldbyte [EMAIL PROTECTED] cc: [EMAIL PROTECTED], freebsd-hackers@freebsd.org, Steven Hartland [EMAIL PROTECTED] On Tue, 19 Apr 2005, Devon Sean McCullough wrote: On Wed, 17 Sep 2003 00:02:33 +0100 Steven Hartland asked this question but no answer was posted. The trouble is likely no client reverse DNS either because it is missing or slow. Adding the client to /etc/hosts on the server seems at first to do nothing but after a minute or so it stops hanging and asks for a password. Could be a coincidence though. To recap: $ ssh -v [EMAIL PROTECTED] OpenSSH_3.4p1+CAN-2004-0175, SSH protocols 1.5/2.0, OpenSSL 0x0090609f debug1: Remote protocol version 1.99, remote software version OpenSSH_3.6.1p1 FreeBSD-20030423 debug1: match: OpenSSH_3.6.1p1 FreeBSD-20030423 pat OpenSSH* Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.4p1+CAN-2004-0175 debug1: got SSH2_MSG_SERVICE_ACCEPT ---Here the client hangs until timeout. To debug: kill the server process and run # sshd -ddde debug3: Trying to reverse map address ... ---Here the server hangs until timeout. Dude, that was 2 years ago in 2003 the year now is 2005 and the current date is 'Wed Apr 20 12:32:31 UTC 2005' so umm, am I living in the future or are you dwelling on the past ???. -- ( When in doubt, use brute force. -- Ken Thompson 1998 ) This trouble hit me yesterday, 2005 Apr 19 Tue, Google led me to someone else with the exact same trouble. What use to ask the net if nobody publishes an ANSWER? A good netizen does the right thing. By citing the original question, I create a link to a possible answer. Peace --Devon /~\ \ /Health Care X not warfare / \ Dubya won the digital vote Kerry won the popular vote PS: Can you identify the presumably slavic language of blagodarq za izpratenoto ot Vas pismo nai skoro shte vi otgovorq!! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel programming
On Wed, 20 Apr 2005 [EMAIL PROTECTED] wrote: yeah thanks for that, i figured the code was a good start. Now that I know the docs i know where to go, cheers for that --neuro On Wed, 20 Apr 2005, Joseph Koshy wrote: where's a good place for kernel programming documentation ? In no particular order: 1. The FreeBSD Developer's Handbook. 2. The FreeBSD Architecture Handbook. 3. The book 'The Design and Implementation of the FreeBSD Operating System', by Kirk McKusick and George Neville-Neil. 3. The section 9 manual pages. 4. The source code :). I like these too (the above is a good list): man 7 development gives a nice model and tutorial to setup an environment. man 7 build documents some of the /usr/src/ targets for make. 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: sshd dieing? after applying FreeBSD-SA-03:12.openssh
c0ldbyte wrote: Dude, that was 2 years ago in 2003 the year now is 2005 and the current date is 'Wed Apr 20 12:32:31 UTC 2005' so umm, am I living in the future or are you dwelling on the past ???. Hey, dude, you aren't helping situations around here. This is one of many inflammatory remarks you've made in recent months. However, I don't believe you're doing it for the express purpose of trolling, so I'm going to give you the benefit of the doubt and advise you. I don't care for your attitude around here, not that that really means anything, but I'm sure others don't either. This is a public list and people are allowed to ask questions. No matter if you, or I, or anyone else considers them stupid. Asking for aid is what the lists are here for. Certain questions might be better directed to questions@ or current@, however, none deserve the treatment you are giving them. None of us have belittled you when you asked questions, you should extend others the same courtesy. You appear to have interest in FreeBSD and I don't want to turn anyone away from it or put a sour taste in their mouth. I have loved the same OS for a long time and like to watch it grow with new list membership, yours the same, however, hang the 'tude at the door and realize this isn't IRC. We help people here instead of giving them a snide remark and say, RTFM. Sincerely Ryan. -- Ryan Sommers [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: sshd dieing? after applying FreeBSD-SA-03:12.openssh
Sorry I don't remember the solution we came up with. It was a long time ago. I think it was to do with DNS invalid / broken DNS or something like that but I couldn't say for sure. Regards Steve - Original Message - From: [EMAIL PROTECTED] This trouble hit me yesterday, 2005 Apr 19 Tue, Google led me to someone else with the exact same trouble. What use to ask the net if nobody publishes an ANSWER? A good netizen does the right thing. By citing the original question, I create a link to a possible answer. This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ABV.BG автоматичен отговор
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 20 Apr 2005 [EMAIL PROTECTED] wrote:
i'm not sure i understnad that language ?
if you tell me which one it is I could use googles convertor
--neuro
On Wed, 20 Apr 2005 freebsd-hackers@freebsd.org wrote:
blagodarq za izpratenoto ot Vas pismo nai skoro shte vi otgovorq!!
This guy/gal we will call The so-called idiot has subscribed to the
mailing list and turned his autoreply for his webmail on. So every
time there is a posting to a certain list his email address autogens
a response and sends it back out to the original sender of the mail.
This is in turn something that mailing list software should protect
against otherwise we could have a nice flood of webmail autoreply
DoS's. I have added a procmail recipe to my $HOME/.procmailrc to
delete these emailings along with other unwanted stuff from idiots
like this one allready just to solve the problem until someone
comes up with a great idea to add a repeat mailing filter (hint)
to the mailing lists. Following is a procmailrc example for removing
email from hosts that you dont want.
# Begin $HOME/.procmailrc
SHELL=/bin/sh
PATH=/bin:/usr/bin:/usr/local/bin
MAILDIR=$HOME/mail
DEFAULT=/var/mail/$LOGNAME
LOGFILE=$HOME/log/procmail.log # Comment this out for no logs
MAIL_ALLOW=$HOME/.procmail/mail.allow # List of allowed host patterns
MAIL_DENY=$HOME/.procmail/mail.deny # List of denied host patterns
:0:
* ? formail -xFrom -xFrom: -xSender: \
-xReply-To: -xReturn-Path: -xReceived: \
| egrep -is -f $MAIL_DENY
DROPBOX
:0:
* ? formail -xFrom -xFrom: -xSender: \
-xReply-To: -xReturn-Path: -xReceived: \
| egrep -is -f $MAIL_ALLOW
${DEFAULT}
# End of $HOME/.procmailrc
Now just setup a couple of things. Make sure you have procmail
installed. Create the $HOME/.procmailrc with the contents above.
mkdir $HOME/log for log files. mkdir $HOME/.procmail for keeping
the mail.allow and mail.deny filter files. Make sure to at least
touch $HOME/.procmail/mail.allow $HOME/.procmail/mail.deny.
All done and set, you can start adding your host patterns to
mail.deny or mail.allow in the form of any of the following.
[EMAIL PROTECTED], [EMAIL PROTECTED], host.net, .host.net, @host.net,
hostname.host.net. I would reccomend adding just single words
to the deny file just for the reason of it will match if the
word shows up anywhere in the fields that it greps and return
true and ultimately dumping your mail to a DROPBOX. You can
also change the DROPBOX part to a absolute path like /dev/null
as well.
Now just add the following to your $HOME/.forward file
and youll have some easy filters setup for your control.
|IFS=' ' exec /usr/local/bin/procmail -Yf- || exit 75 #USERNAME
^^^ including the double quotes ^^^
Best of luck.
--c0ldbyte
- --
( When in doubt, use brute force. -- Ken Thompson 1998 )
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (FreeBSD)
Comment: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xF7DF979F
Comment: Fingerprint = D1DC 0AA4 1C4E EAD4 24EB 7E77 B261 50BA F7DF 979F
iD8DBQFCZlV6smFQuvffl58RAsThAJ96zhD7mB9b+39MWEGjXtgcMNdBewCcC7rm
iFxaMo+CsMM0SbYr1pIP8qE=
=ZeOL
-END PGP SIGNATURE-
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sshd dieing? after applying FreeBSD-SA-03:12.openssh
Steven Hartland wrote: Sorry I don't remember the solution we came up with. It was a long time ago. I think it was to do with DNS invalid / broken DNS or something like that but I couldn't say for sure. Regards Steve - Original Message - From: [EMAIL PROTECTED] This trouble hit me yesterday, 2005 Apr 19 Tue, Google led me to someone else with the exact same trouble. What use to ask the net if nobody publishes an ANSWER? A good netizen does the right thing. By citing the original question, I create a link to a possible answer. I seem to remember updating the /etc/named/named.root file on a box, and that fixed it for me.. I can't recall for sure, but you might give that a shot. Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology A lost ounce of gold may be found, a lost moment of time never. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ABV.BG автоматичен отговор
On Wed, 20 Apr 2005 freebsd-hackers@freebsd.org wrote: blagodarq za izpratenoto ot Vas pismo nai skoro shte vi otgovorq!! Sir, this is not the appropriate forum to cast your vote for Pope. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sshd dieing? after applying FreeBSD-SA-03:12.openssh
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 20 Apr 2005, Ryan Sommers wrote: c0ldbyte wrote: Dude, that was 2 years ago in 2003 the year now is 2005 and the current date is 'Wed Apr 20 12:32:31 UTC 2005' so umm, am I living in the future or are you dwelling on the past ???. Hey, dude, you aren't helping situations around here. This is one of many inflammatory remarks you've made in recent months. However, I don't believe you're doing it for the express purpose of trolling, so I'm going to give you the benefit of the doubt and advise you. I don't care for your attitude around here, not that that really means anything, but I'm sure others don't either. This is a public list and people are allowed to ask questions. No matter if you, or I, or anyone else considers them stupid. Asking for aid is what the lists are here for. Certain questions might be better directed to questions@ or current@, however, none deserve the treatment you are giving them. None of us have belittled you when you asked questions, you should extend others the same courtesy. You appear to have interest in FreeBSD and I don't want to turn anyone away from it or put a sour taste in their mouth. I have loved the same OS for a long time and like to watch it grow with new list membership, yours the same, however, hang the 'tude at the door and realize this isn't IRC. We help people here instead of giving them a snide remark and say, RTFM. Sincerely Ryan. Well first off that wasnt a snide remark. Second off it was sort of a off lead question of why this was brought up now since it happened 2 or more years ago, but sorry you didnt catch that and that I didnt make that more clear. Third off I dont tell people to RTFM unless I allready know that its defined in the manual and they are asking basic questions that should have allready easyily been picked up from the manual which tells other that they have not read the manual correctly correct ?. Anyhow that email that I sent that Im replying to now was not meant to be taken in any harsh way. That email in question was more of a fundamental way to extract certain information on why things are the way they are now and get more insight in a less direct way. But I appologize to any of you that may have felt hurt or upset at the way that email was written and I tend to do alot of that sometimes due to hell I dont know just do I guess but anywho best of luck to all of ya. PS: Dont mean to offend anyone. If I have drop my name in your ignore list. Email dont have to be read just because its there. Best wishes. --c0ldbyte - -- ( When in doubt, use brute force. -- Ken Thompson 1998 ) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (FreeBSD) Comment: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xF7DF979F Comment: Fingerprint = D1DC 0AA4 1C4E EAD4 24EB 7E77 B261 50BA F7DF 979F iD8DBQFCZlqRsmFQuvffl58RAkfUAJkBfSQe3i3/6fhP7eAK6P6mOe0ligCfVJc6 wyBxXHD3l0diy6iAO8BT+w4= =5r0w -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Configuration differences for jails
Hi, I am now trying to use jail in FreeBSD. I have read the jail(8) man page and some others documents for setting up jails. But I'm a little confused about the procedure and configurations for setting up jails. As known to all, jail can be used for two purposes, i.e. jailing a single application or acting as a virtual host. What i want to know is the concrete configuration (procedure) difference between the two types use of jails. Is there a SMALLEST set of configuration necessary for setting up a jail? If so, what is it? Another question, is there any way to detect the share of files between multiple jails automatically? The following is based on my own experience and therefore may not be what other people feel. I run two main services on a box, Bind and Postfix, and I wanted to separate each other from the base system for security reason. I thought it was quite heavy to boot two virtual hosts as described in the jail(8) manpage for two daemons only, so I decided to just jail each application. In all cases, I strongly wanted the chosen setup to create a very few overhead compared to what it would be without jail. In the per-application case, you will have to be very careful about the things that will be needed by the daemon (dynamic libraries and configuration files as well as spool queues, mailboxes or maildirs, and other filesystem objects such as Unix domain sockets, named pipes, ...) Since I wanted this setup to be as transparent as possible, I decided to null mounts all needed directories from host to jail root, in order to be able to execute administrative commands (postconf(8), mailq(8), ...) from host itself. One exception is /etc : you don't want to null mount it into the jail as it contains very sensible informations like password hashes ; you will have to manually synchronize resolv.conf, localtime, aliases, ... Now with some distance, I must admit that all this gymnastic is quite boring. I now decided to run two virtual hosts as they are managed in a very natural way. These two hosts are just like two real boxes, one running Bind and the other one running Postfix. When I need to update something in the configuration, I login to the box with ssh(1). This take some more memory and in principle no CPU as all processes are sleeping most of the time. BTW, what is the meaning of IMHO? :) It appears very frequently in the mail list. The port games/wtf will translate acronyms for you. %%% obiwan:ports$ wtf IMHO IMHO: in my humble opinion %%% Regards, -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS client/buffer cache deadlock
On Tue, Apr 19, 2005 at 04:47:23PM -0400, Brian Fundakowski Feldman wrote: This compiles. It does and it seems to work. The NFS performance drops considerably though, from 8/9 MByte/s to 3/4 on sequential reads for instance. kern/79208 is fixed by this indeed, in that I get short writes (in case of my test server at 1802240+ bytes, so './writev 2 foo' fails... Marc pgppI0qQA9pN4.pgp Description: PGP signature
Re: sshd dieing? after applying FreeBSD-SA-03:12.openssh
Usually do post answers when I find them but it was one of those must get it fixed 24 hour jobs as I recall so just slipped way as I fell asleep :) Could be its forcing a name resolution and not using hosts at all? Steve - Original Message - From: [EMAIL PROTECTED] In the future, please do as I did and publish whatever solution you find, my answer was somewhat lame but worked for me and will help the next guy. To the SSH server /etc/hosts I added the client machine, now when it gets to debug1: got SSH2_MSG_SERVICE_ACCEPT it hangs for only 75 seconds. This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS client/buffer cache deadlock
On Wed, Apr 20, 2005 at 04:04:09PM +0200, Marc Olzheim wrote: On Tue, Apr 19, 2005 at 04:47:23PM -0400, Brian Fundakowski Feldman wrote: This compiles. It does and it seems to work. The NFS performance drops considerably though, from 8/9 MByte/s to 3/4 on sequential reads for instance. kern/79208 is fixed by this indeed, in that I get short writes (in case of my test server at 1802240+ bytes, so './writev 2 foo' fails... Performance drops in what cases? -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Configuration differences for jails
Now with some distance, I must admit that all this gymnastic is quite boring. I now decided to run two virtual hosts as they are managed in a very natural way. These two hosts are just like two real boxes, one running Bind and the other one running Postfix. When I need to update something in the configuration, I login to the box with ssh(1). This take some more memory and in principle no CPU as all processes are sleeping most of the time. I forgotten to explain that using virtual hosts require some administration too in order to avoid wasting disk space. The jail(8) manual page advices to make world with DESTDIR set. I prefer using null mounts as it doesn't require additional disk space and an upgrade of the host will automagically upgrade virtual hosts. You will nevertheless have to make distribution and distrib-dirs. Here are the directories I advice you to share : /bin /sbin /lib /libexec /usr/bin /usr/sbin /usr/lib /usr/libexec /usr/libdata /usr/share /usr/doc /usr/compat /usr/ports Sharing ports may be more difficult as it may require sharing the port database, but I think it's still possible. -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS client/buffer cache deadlock
On Wed, Apr 20, 2005 at 10:24:48AM -0400, Brian Fundakowski Feldman wrote: It does and it seems to work. The NFS performance drops considerably though, from 8/9 MByte/s to 3/4 on sequential reads for instance. kern/79208 is fixed by this indeed, in that I get short writes (in case of my test server at 1802240+ bytes, so './writev 2 foo' fails... Performance drops in what cases? Hmm, seems only to happen in large sequential reads... It might just be the FreeBSD 4.6 NFS server that is the problem though. I've had more NFS troubles with it. Btw.: I'm not sure write(),writev() and pwrite() are allowed to do short writes on regular files... ? Marc pgpUDg3wAPZRx.pgp Description: PGP signature
gvinum during bootup
I'm running a FreeBSD6 machine current as of a few days ago and I'm
working on a gvinum configuration, I couldn't find any place where it
referenced gvinum on startup so after fussing around with the rc
system a little, I wrote an /etc/rc.d/gvinum script that looks like
so:
#!/bin/sh
# PROVIDE: disks
# KEYWORD: nojail
. /etc/rc.subr
name=gvinum
start_cmd=gvinum_start
stop_cmd=:
gvinum_start()
{
case ${gvinum_enable} in
[Yy][Ee][Ss])
echo starting gvinum.
/sbin/gvinum start
;;
esac
}
load_rc_config $name
run_rc_command $1
# END
I then added
gvinum_enable=YES
to my /etc/rc.conf and it seems to be working great. rcorder tells
me this is run a few steps before ccd, which is confusing because I
used the same keywords and ccd isn't requested anywhere.
is there some place this can be added to -current? I'm assuming the
change from vinum to gvinum is still in some sort of transition.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
gvinum during bootup
I'm running a FreeBSD6 machine current as of a few days ago and I'm
working on a gvinum configuration, I couldn't find any place where it
referenced gvinum on startup so after fussing around with the rc
system a little, I wrote an /etc/rc.d/gvinum script that looks like
so:
#!/bin/sh
# PROVIDE: disks
# KEYWORD: nojail
. /etc/rc.subr
name=gvinum
start_cmd=gvinum_start
stop_cmd=:
gvinum_start()
{
case ${gvinum_enable} in
[Yy][Ee][Ss])
echo starting gvinum.
/sbin/gvinum start
;;
esac
}
load_rc_config $name
run_rc_command $1
# END
I then added
gvinum_enable=YES
to my /etc/rc.conf and it seems to be working great. rcorder tells
me this is run a few steps before ccd, which is confusing because I
used the same keywords and ccd isn't requested anywhere.
is there some place this can be added to -current? I'm assuming the
change from vinum to gvinum is still in some sort of transition.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Configuration differences for jails
* Jeremie Le Hen [EMAIL PROTECTED] [20050420 16:37]:
Now with some distance, I must admit that all this gymnastic is quite
boring. I now decided to run two virtual hosts as they are managed in
a very natural way. These two hosts are just like two real boxes, one
running Bind and the other one running Postfix. When I need to update
something in the configuration, I login to the box with ssh(1). This
take some more memory and in principle no CPU as all processes are
sleeping most of the time.
I forgotten to explain that using virtual hosts require some
administration too in order to avoid wasting disk space. The jail(8)
manual page advices to make world with DESTDIR set. I prefer using
null mounts as it doesn't require additional disk space and an upgrade
of the host will automagically upgrade virtual hosts. You will
nevertheless have to make distribution and distrib-dirs. Here are the
directories I advice you to share :
/bin /sbin /lib /libexec
/usr/bin /usr/sbin /usr/lib /usr/libexec /usr/libdata /usr/share
/usr/doc /usr/compat /usr/ports
I'm trying to untangle myself on this issue. I have different
filesystems for /, /usr, and /usr/local, mounted in unusual places:
504,p0,1$ ls -l /usr{,/X11R6,/local}
lrwxr-xr-x 1 root wheel 18 7 nov 2003 /usr - fs/base/mount/usr/
lrwxr-xr-x 1 root wheel 25 8 nov 2003 /usr/X11R6 -
../../../apps/mount/X11R6
lrwxr-xr-x 1 root wheel 25 18 abr 20:40 /usr/local -
../../../apps/mount/local
I know I want to share /usr, but not /usr/local, and only parts of /. So
I mount_unionfs /fs/base inside the jail:
above:/fs/base/mount on /fs/jaildata/mount/fs/base/mount (unionfs,
local, read-only, noclusterw)
But this way I don't get the automagically upgrade virtual hosts
behaviour I want, since I'm missing /{,s}bin, /lib and /libexec and I
definitely don't want to share /etc.
I don't think it's easy to take /etc/ outside the root fs, but I don't
see how to share /bin or /lib without leaking info.
How do you handle this? What are those distribution targets and how can
I use them?
tks
--
pica
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS client/buffer cache deadlock
On Wed, Apr 20, 2005 at 04:38:42PM +0200, Marc Olzheim wrote: On Wed, Apr 20, 2005 at 10:24:48AM -0400, Brian Fundakowski Feldman wrote: It does and it seems to work. The NFS performance drops considerably though, from 8/9 MByte/s to 3/4 on sequential reads for instance. kern/79208 is fixed by this indeed, in that I get short writes (in case of my test server at 1802240+ bytes, so './writev 2 foo' fails... Performance drops in what cases? Hmm, seems only to happen in large sequential reads... It might just be the FreeBSD 4.6 NFS server that is the problem though. I've had more NFS troubles with it. Reads should be totally unaffected... Btw.: I'm not sure write(),writev() and pwrite() are allowed to do short writes on regular files... ? Our manpage is incorrect; POSIX states that they are (see earlier e-mail). There really is no alternative -- we simply can't build an NFS transaction larger than our buffer cache can accomodate. Note that short wries won't happen for normal buffer sizes, only excessively large ones. I really don't believe that writev() is meant to be used so that you can write gigantic data structures in a single transaction... -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS client/buffer cache deadlock
On Wed, Apr 20, 2005 at 11:20:38AM -0400, Brian Fundakowski Feldman wrote: Reads should be totally unaffected... The server was misbehaving. Fixed. :-) Btw.: I'm not sure write(),writev() and pwrite() are allowed to do short writes on regular files... ? Our manpage is incorrect; POSIX states that they are (see earlier e-mail). There really is no alternative -- we simply can't build an NFS transaction larger than our buffer cache can accomodate. Note that short wries won't happen for normal buffer sizes, only excessively large ones. I really don't believe that writev() is meant to be used so that you can write gigantic data structures in a single transaction... Ah, I was reading the SUSv2 page: http://www.opengroup.org/onlinepubs/009695399/functions/write.html instead of the POSIX version. But in neither of those I can extrude the fact that it can return with result nbyte, without it being a permanent condition. What phrase makes you conclude that it can ? Marc pgpWq1uSfqyaE.pgp Description: PGP signature
Re: NFS client/buffer cache deadlock
On Wed, Apr 20, 2005 at 05:35:28PM +0200, Marc Olzheim wrote: On Wed, Apr 20, 2005 at 11:20:38AM -0400, Brian Fundakowski Feldman wrote: Reads should be totally unaffected... The server was misbehaving. Fixed. :-) Btw.: I'm not sure write(),writev() and pwrite() are allowed to do short writes on regular files... ? Our manpage is incorrect; POSIX states that they are (see earlier e-mail). There really is no alternative -- we simply can't build an NFS transaction larger than our buffer cache can accomodate. Note that short wries won't happen for normal buffer sizes, only excessively large ones. I really don't believe that writev() is meant to be used so that you can write gigantic data structures in a single transaction... Ah, I was reading the SUSv2 page: http://www.opengroup.org/onlinepubs/009695399/functions/write.html instead of the POSIX version. But in neither of those I can extrude the fact that it can return with result nbyte, without it being a permanent condition. What phrase makes you conclude that it can ? This specific issue is not clear-cut; the best thing to do lies somewhere within the range of these scenarios: If a write() requests that more bytes be written than there is room for (for example, [XSI] [Option Start] the process' file size limit or [Option End] the physical end of a medium), only as many bytes as there is room for shall be written. For example, suppose there is space for 20 bytes more in a file before reaching a limit. A write of 512 bytes will return 20. The next write of a non-zero number of bytes would give a failure return (except as noted below). When attempting to write to a file descriptor (other than a pipe or FIFO) that supports non-blocking writes and cannot accept the data immediately: * If the O_NONBLOCK flag is clear, write() shall block the calling thread until the data can be accepted. * If the O_NONBLOCK flag is set, write() shall not block the thread. If some data can be written without blocking the thread, write() shall write what it can and return the number of bytes written. Otherwise, it shall return -1 and set errno to [EAGAIN]. [ENOBUFS] Insufficient resources were available in the system to perform the operation. I think the first is more useful behavior than the last. Supporting it should be exactly the same as supporting what happens if the actual filesystem fills up. In this case, the filesystem is being requested to write more than there is room for. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Configuration differences for jails
I'm trying to untangle myself on this issue. I have different
filesystems for /, /usr, and /usr/local, mounted in unusual places:
504,p0,1$ ls -l /usr{,/X11R6,/local}
lrwxr-xr-x 1 root wheel 18 7 nov 2003 /usr - fs/base/mount/usr/
lrwxr-xr-x 1 root wheel 25 8 nov 2003 /usr/X11R6 -
../../../apps/mount/X11R6
lrwxr-xr-x 1 root wheel 25 18 abr 20:40 /usr/local -
../../../apps/mount/local
I know I want to share /usr, but not /usr/local, and only parts of /. So
I mount_unionfs /fs/base inside the jail:
above:/fs/base/mount on /fs/jaildata/mount/fs/base/mount (unionfs,
local, read-only, noclusterw)
mount_nullfs(8) will mount one directory and all its content onto another
one, but there is no way to exclude one of the subdirectory. You
will instead have to mount each subdirectory you need, not more. One
other way do achieve this is to make a second null mount over the
directory you don't wan't to share (/usr/local) but I'm not aware of
the consequences of such setup in term of performance and stability.
But this way I don't get the automagically upgrade virtual hosts
behaviour I want, since I'm missing /{,s}bin, /lib and /libexec and I
definitely don't want to share /etc.
You won't have a one to one mapping between jail and null mounts. There
are generally multiple null mounts for a unique jail.
Considering your jail root is /jail/test, and you enabled the
jail_$jail_mount (jail_test_mount here) rc.conf(5) variable, here is
the content of /etc/fstab.test :
%%%
/bin/jail/test/bin nullfs ro 0 0
/sbin /jail/test/sbin nullfs ro 0 0
/lib/jail/test/lib nullfs ro 0 0
/libexec/jail/test/libexec nullfs ro 0 0
/usr/bin/jail/test/usr/bin nullfs ro 0 0
/usr/sbin /jail/test/usr/sbin nullfs ro 0 0
/usr/lib/jail/test/usr/lib nullfs ro 0 0
/usr/libexec/jail/test/usr/libexec nullfs ro 0 0
/usr/libdata/jail/test/usr/libdata nullfs ro 0 0
/usr/share /jail/test/usr/sharenullfs ro 0 0
/usr/compat /jail/test/usr/compat nullfs ro 0 0
%%%
I don't think it's easy to take /etc/ outside the root fs, but I don't
see how to share /bin or /lib without leaking info.
How do you handle this? What are those distribution targets and how can
I use them?
As I said above, null mount each directory.
Regards,
--
Jeremie Le Hen
jeremie at le-hen dot org ttz at chchile dot org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS client/buffer cache deadlock
On Wed, Apr 20, 2005 at 11:52:33AM -0400, Brian Fundakowski Feldman wrote: On Wed, Apr 20, 2005 at 05:35:28PM +0200, Marc Olzheim wrote: On Wed, Apr 20, 2005 at 11:20:38AM -0400, Brian Fundakowski Feldman wrote: Btw.: I'm not sure write(),writev() and pwrite() are allowed to do short writes on regular files... ? Our manpage is incorrect; POSIX states that they are (see earlier e-mail). There really is no alternative -- we simply can't build an NFS transaction larger than our buffer cache can accomodate. Note that short wries won't happen for normal buffer sizes, only excessively large ones. I really don't believe that writev() is meant to be used so that you can write gigantic data structures in a single transaction... It is ok to return partial success if the first chunk of a large write succeeded and a later chunk failed persistently, but not if it cannot be performed as a single NFS transaction. Ah, I was reading the SUSv2 page: http://www.opengroup.org/onlinepubs/009695399/functions/write.html instead of the POSIX version. But in neither of those I can extrude the fact that it can return with result nbyte, without it being a permanent condition. What phrase makes you conclude that it can ? This specific issue is not clear-cut; the best thing to do lies somewhere within the range of these scenarios: If a write() requests that more bytes be written than there is room for (for example, [XSI] [Option Start] the process' file size limit or [Option End] the physical end of a medium), only as many bytes as there is room for shall be written. For example, suppose there is space for 20 bytes more in a file before reaching a limit. A write of 512 bytes will return 20. The next write of a non-zero number of bytes would give a failure return (except as noted below). This only applies to permanent conditions. When attempting to write to a file descriptor (other than a pipe or FIFO) that supports non-blocking writes and cannot accept the data immediately: * If the O_NONBLOCK flag is clear, write() shall block the calling thread until the data can be accepted. * If the O_NONBLOCK flag is set, write() shall not block the thread. If some data can be written without blocking the thread, write() shall write what it can and return the number of bytes written. Otherwise, it shall return -1 and set errno to [EAGAIN]. I think regular files do not support non-blocking writes, even if they are on NFS; in any case, O_NONBLOCK is disabled by default. [ENOBUFS] Insufficient resources were available in the system to perform the operation. I think the first is more useful behavior than the last. Supporting it should be exactly the same as supporting what happens if the actual filesystem fills up. In this case, the filesystem is being requested to write more than there is room for. The filesystem filling up is a totally different case as attempting the rest of the write is futile in that case. In a lot of code, a short write() is treated as a (fairly) persistent error. -- Jilles Tjoelker ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS client/buffer cache deadlock
On Wed, Apr 20, 2005 at 07:12:20PM +0200, Jilles Tjoelker wrote: On Wed, Apr 20, 2005 at 11:52:33AM -0400, Brian Fundakowski Feldman wrote: On Wed, Apr 20, 2005 at 05:35:28PM +0200, Marc Olzheim wrote: On Wed, Apr 20, 2005 at 11:20:38AM -0400, Brian Fundakowski Feldman wrote: Btw.: I'm not sure write(),writev() and pwrite() are allowed to do short writes on regular files... ? Our manpage is incorrect; POSIX states that they are (see earlier e-mail). There really is no alternative -- we simply can't build an NFS transaction larger than our buffer cache can accomodate. Note that short wries won't happen for normal buffer sizes, only excessively large ones. I really don't believe that writev() is meant to be used so that you can write gigantic data structures in a single transaction... It is ok to return partial success if the first chunk of a large write succeeded and a later chunk failed persistently, but not if it cannot be performed as a single NFS transaction. What is your rationale for this? Ah, I was reading the SUSv2 page: http://www.opengroup.org/onlinepubs/009695399/functions/write.html instead of the POSIX version. But in neither of those I can extrude the fact that it can return with result nbyte, without it being a permanent condition. What phrase makes you conclude that it can ? This specific issue is not clear-cut; the best thing to do lies somewhere within the range of these scenarios: If a write() requests that more bytes be written than there is room for (for example, [XSI] [Option Start] the process' file size limit or [Option End] the physical end of a medium), only as many bytes as there is room for shall be written. For example, suppose there is space for 20 bytes more in a file before reaching a limit. A write of 512 bytes will return 20. The next write of a non-zero number of bytes would give a failure return (except as noted below). This only applies to permanent conditions. When attempting to write to a file descriptor (other than a pipe or FIFO) that supports non-blocking writes and cannot accept the data immediately: * If the O_NONBLOCK flag is clear, write() shall block the calling thread until the data can be accepted. * If the O_NONBLOCK flag is set, write() shall not block the thread. If some data can be written without blocking the thread, write() shall write what it can and return the number of bytes written. Otherwise, it shall return -1 and set errno to [EAGAIN]. I think regular files do not support non-blocking writes, even if they are on NFS; in any case, O_NONBLOCK is disabled by default. POSIX does not specify O_NONBLOCK semantics for regular files. This means we can do whatever is most useful. [ENOBUFS] Insufficient resources were available in the system to perform the operation. I think the first is more useful behavior than the last. Supporting it should be exactly the same as supporting what happens if the actual filesystem fills up. In this case, the filesystem is being requested to write more than there is room for. The filesystem filling up is a totally different case as attempting the rest of the write is futile in that case. No, it isn't. The filesystem may be not-full again soon, possibly even what the program might consider immediately. In a lot of code, a short write() is treated as a (fairly) persistent error. I mentioned this several e-mails ago. Plenty of software is also not going to understand ENOBUFS. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS client/buffer cache deadlock
On Wed, Apr 20, 2005 at 01:29:10PM -0400, Garrett Wollman wrote: On Wed, 20 Apr 2005 11:52:33 -0400, Brian Fundakowski Feldman [EMAIL PROTECTED] said: I think the first is more useful behavior than the last. Supporting it should be exactly the same as supporting what happens if the actual filesystem fills up. In this case, the filesystem is being requested to write more than there is room for. Returning a short write for operations on regular files would definitely be considered astonishing. The changes that you have made should be considered flow control, not admission control, and should appear to the user no differently than if we were waiting for a slow disk to write something; i.e., the user thread should be blocked until either the entire write completes, or the process is interrupted by a signal. So what _would_ be consistent for nfs_bio.c::nfs_write()? IO_UNIT is set for all write calls which means atomic, and nfs_rslock() and O_APPEND appear to at least attempt this. Please take a detailed look at the current system and the changes... it's far less clear-cut than POLA dictates. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS client/buffer cache deadlock
On Wed, Apr 20, 2005 at 01:28:39PM -0400, Brian Fundakowski Feldman wrote: It is ok to return partial success if the first chunk of a large write succeeded and a later chunk failed persistently, but not if it cannot be performed as a single NFS transaction. What is your rationale for this? Probably the part that you quoted about the write() after the short write() supposedly returning an error. Besides from that: since it isn't non-blocking, why not just block until everything is written ? That's the way it is done on FreeBSD 4.x and that's how I interpret the standards... Marc pgpNhQ8LW1bCB.pgp Description: PGP signature
Re: 5.4-RC2 keyboard problem on Dell PowerEdge 2850
Sawek ak wrote: On 4/18/05, c0ldbyte [EMAIL PROTECTED] wrote: On Mon, 18 Apr 2005, [ISO-8859-2] Sawek ak wrote: Hi, After install from CD the keyboard doesn't work on this machine. Has anyone else seen it? /S Select the correct key map screen map etc... ? Erm. When I say keyboard doesn't work I *mean* it doesn't work at all. The only key which works on the box is BRS, which doesn't give me sufficient interaction with the system. I've skipped morse code lessons and boy scouting in my life altogether. Did you get this solved? I have some Dell 2850's I might be able to test this on. Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology A lost ounce of gold may be found, a lost moment of time never. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Last REMINDER! Call for FreeBSD status reports
All, Last call for the quartly status report! If you still intent to submit one, please do so in the next 12 hours. Also, I'd like to remind everyone that submission are open to everyone, not just FreeBSD developers. We welcome all reports on projects and events in the FreeBSD community. Scott Scott Long wrote: All, This is a reminder that status reports are due. We are going to extend the deadline until the 20th to encourage people to submit a few more reports. If you have any projects that you've been working on in the past 3 months that are interesting and you would like to share, please submit a report as soon as possible. The new web form from Julian makes it incredibly easy to generate a submission without having to know a thing about XML. The link for this is at: http://www.freebsd.org/cgi/monthly.cgi So, please submit your reports to [EMAIL PROTECTED] by the 20th. Thanks, Scott Long, Max Laier, Tom Rhodes Max Laier wrote: All, It's time again for some recapitulation of your FreeBSD activities of the last months. In order to not collided with the preparation of the 5.4 release we extended the cycle from bi-monthly to three months, so this one is open for anything that happend in 2005 until now. Submissions are due by April 15 to [EMAIL PROTECTED] As always, reports about every FreeBSD related activity of the past months and coming weeks are welcome. In the past there was some focus on technical issues. In order to turn this into a more complete PR-vehicle, we highly encourage and welcome reports on non-technical matters as well. If you are yet unfamiliar with the status-reports, please take a look at the past reports: http://www.FreeBSD.org/news/status/ To support you in the process of fitting your report into the xml-template (available from: http://www.freebsd.org/news/status/report-sample.xml for those who still prefer a plain old text editor) Julian Elischer came up with the idea and prototype to have a web based form. Many thanks for that work. The cgi-script is being reviewed on freebsd-www now and will be linked to from http://www.freebsd.org/news/status/ shortly. The new features from last time (categories and task-list) will be available, again. As a reminder the available categories are listed bellow. Please feel free to suggest additional entries: proj - Projects (non-specific) docs - Documentation kern - Kernel arch - Architectures ports - Ports vendor - Vendor / 3rd party software misc - Miscellaneous Submissions are due on April 15. Thanks a lot, and we are hoping for a big turn-out. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
what goes wrong with barrier free atomic_load/store?
in reading /src/sys/i386/include/atomic.h I found this comment and I'm having trouble understanding what the problem being referred to below is. /* * We assume that a = b will do atomic loads and stores. However, on a * PentiumPro or higher, reads may pass writes, so for that case we have * to use a serializing instruction (i.e. with LOCK) to do the load in * SMP kernels. For UP kernels, however, the cache of the single processor * is always consistent, so we don't need any memory barriers. */ can someone give me an example of a situation where one needs to use memory barriers to ensure correctness when doing writes as above? the examples I can come up with seem to boil down to requiring locks or accepting stale values, given that without a synchronization mechanism one shouldn't expect two processes to act in any specific order. In my case I can accept reading a stale value so I'm not understanding the purpose of only having atomic_load/atomic_store wrappers with memory barriers. I saw a brief discussion where someone proposed barrier free load/store but don't think I saw any resolution. thanks, John G -- [EMAIL PROTECTED] University of Colorado at Boulder Department of Computer Science Engineering Center, ECCS 121 430 UCB Boulder, CO 80303-0430 USA ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: what goes wrong with barrier free atomic_load/store?
On Wed, 2005-04-20 at 16:39, John Giacomoni wrote:
in reading /src/sys/i386/include/atomic.h
I found this comment and I'm having trouble understanding what the
problem being
referred to below is.
/*
* We assume that a = b will do atomic loads and stores. However, on a
* PentiumPro or higher, reads may pass writes, so for that case we have
* to use a serializing instruction (i.e. with LOCK) to do the load in
* SMP kernels. For UP kernels, however, the cache of the single
processor
* is always consistent, so we don't need any memory barriers.
*/
can someone give me an example of a situation where one needs to use
memory barriers to ensure correctness when doing writes as above?
volatile int status = NOT_READY;
volatile int data = -1;
Thread 1: (CPU 0)
--
data = 123;
status = READY;
Thread 2: (CPU 1)
-
if (status == READY) {
my_data = data;
}
Read reordering my the CPUs may cause the following:
Thread 2: out_of_order_read = data;
Thread 1: data = 123;
Thread 1: status = READY;
Thread 2: if (status == READY) {
Thread 2: my_data = out_of_order_read ; /* Unexpected VALUE */
Basically volatile does not work as expected.
the examples I can come up with seem to boil down to requiring locks
or accepting stale values, given that without a synchronization
mechanism
one shouldn't expect two processes to act in any specific order.
The problem is that writes from another CPU (or DMA device) can be
observed out of order.
In my case I can accept reading a stale value so I'm not understanding
the
purpose of only having atomic_load/atomic_store wrappers with memory
barriers.
I saw a brief discussion where someone proposed barrier free load/store
but
don't think I saw any resolution.
Do you mean load/store fences?
A load fence could solve the problem above by preventing the out of
order read of the data by thread 2.
I actually found a race condition close to the one mentioned above in
the kernel yesterday. So we may need to add fences real soon or rewrite
the code to use a spin mutex.
Stephan
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
KLD module with C++ iostreams ?
Hi hackers, I am wondering if I can use c++ iostreams inside the kernel ? After all the code : cout Hello world! endl; ends accessing the stdout just like : printf(Hello world!\n); right ? So if I could compile my KLD module with static linkage to libstdc++, that should be ok, right ? Any one did or knows how to do this ? Thanks, -aziz ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: KLD module with C++ iostreams ?
Interesting question. People usually have to implement the C++ runtime to be usable from within the kernel. Things like exceptions and stdout may not be defined in kernel space :) I'm not terribly familiar with how it works on FreeBSD but I know it took a special effort to get C++ support into linux. Dave On 4/20/05, Aziz KEZZOU [EMAIL PROTECTED] wrote: Hi hackers, I am wondering if I can use c++ iostreams inside the kernel ? After all the code : cout Hello world! endl; ends accessing the stdout just like : printf(Hello world!\n); right ? So if I could compile my KLD module with static linkage to libstdc++, that should be ok, right ? Any one did or knows how to do this ? Thanks, -aziz ___ 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: KLD module with C++ iostreams ?
David Leimbach wrote: Interesting question. People usually have to implement the C++ runtime to be usable from within the kernel. Things like exceptions and stdout may not be defined in kernel space :) I'm not terribly familiar with how it works on FreeBSD but I know it took a special effort to get C++ support into linux. Dave On 4/20/05, Aziz KEZZOU [EMAIL PROTECTED] wrote: Hi hackers, I am wondering if I can use c++ iostreams inside the kernel ? After all the code : cout Hello world! endl; ends accessing the stdout just like : printf(Hello world!\n); right ? No, that's not true, all the iostreams stuff is totally independent. The iostreams stuff is coming from some of the ugliest code in C++. But, that's not the question, or at very least, it shouldn't BE the question. There is ZERO need to bring in features from C++, all it will do is to directly confuse the code base by greatly adding to the complexity of the code, without giving anything like equivalent features. Some very, very elegant work has been code, OO-ing the kernel code, adding OO features, all without violating the C language code base. Adding in C++ features over stdio stuff is so senseless, it's nearly obscene. If the gain at the end of the road was large enough, I wouldn't be against it so stridently, but I see *so* little gain. BTW, you know where the ugliest code in computer science today is: half is in the actual implementation of the cstdio/template code, the other half is the iostreams stuff. The fact that they energize some very elegant code is causing many folks never to see the fact of the horrible code lumps that exist out in the backyard. So if I could compile my KLD module with static linkage to libstdc++, that should be ok, right ? Any one did or knows how to do this ? Thanks, -aziz ___ 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] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: KLD module with C++ iostreams ?
In message: [EMAIL PROTECTED] Aziz KEZZOU [EMAIL PROTECTED] writes: : Hi hackers, : I am wondering if I can use c++ iostreams inside the kernel ? : After all the code : cout Hello world! endl; : ends accessing the stdout just like : printf(Hello world!\n); right ? Just like, yes. Exactly the same thing as, no. The details matter here. There's a lot of code to make this happen. : So if I could compile my KLD module with static linkage to libstdc++, : that should be ok, right ? No. : Any one did or knows how to do this ? I've done C++ in the kernel before. IT is realtively easy to get very basic functioanlity. You won't have streams, exceptions, etc. However, to have all the features of C++ would take a lot of work. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
