RE: Junior Annoying Hacker Task
Hi, I don't know whether the suggested approach is really a good one or not, but as far as implementing some registry-like features in FreeBSD, we have developped something that proves to be useful. The idea was to extend the sysctl mechanism to make it dynamic from the user-land point of view. This was implemented as a kernel module (a simple one too) and a modified sysctl command line. With this mod we can add/remove nodes in the sysctl tree and use it to store information that is needed by many applications. The implementation we have is certainly rough, but it gets the job done and represents a very easy and convenient tool for: - sharing non sensitive bits of information between processes - storing configuration/status data in an easy to use manner - benefit from the tree like presentation of sysctl (building a gui around this should be easy) - don't loose the 'vi' compatibility (sysctl values can be loaded at boot time from a text file) Note that the security model around these 'user-land dynamic sysctl entries' can be improved significantly, but as a proof of concept the mod is useful. Some may argue that storing userland data in the kernel space is Not A Nice Thing(tm) but it certainly makes things a lot easier. Patrick. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: vn, vnconfig and MFS death-warrant!
"Poul-Henning Kamp" [EMAIL PROTECTED] wrote in message news:29877.980850630@critter... I have made mount_mfs and vnconfig print a warning and sleep for 15 seconds before continuing. Please convert to using mdconfig(8) for TMPFS uses. March 1st I will remove the functionality from mount_mfs and vnconfig, leaving only the message which will be an error obviously. April 1st I will remove vn, vnconfig and mount_mfs entirely. Could these modifications be ported to -STABLE to ease up the transition from -STABLE to -CURRENT ? I don't know if this is tied deeply on other changes in -CURRENT, but if it is not I'd like to use the new facility. Let me know if you want me to do some testing prior to committing the changes to -STABLE. I will happily contribute any help I can. Patrick. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: vn, vnconfig and MFS death-warrant!
Hi, Could these modifications be ported to -STABLE to ease up the transition from -STABLE to -CURRENT ? I don't know if this is tied deeply on other changes in -CURRENT, but if it is not I'd like to use the new facility. I think I would rather leave -stable out of this for now. There are too many deployed production systems I think. Just to make my intentions clear, I am not asking to remove vn/vnconfig(8)/mfs from -STABLE, I was just asking for the inclusion of md/mdconfig in -STABLE so that people (at least me :) ) can get ready for the day 5.0 will becomes -STABLE... My other problem is that I use vn's heavily and I find that some of their limitations are really annoying. While I could hack the relevent code to make myself happy, I think that there is little value in me doing that when it is obvious that they are going away in the not so distant future (5.0). Anyway, this is not a big deal. Patrick. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: status of bridge code
Hi, But from my list of wishes I'd say the first 3 are gone. All that's left is spanning tree. I'm probably going to need this pretty soon, so once more I'm asking if anyone is working on it. If not I'll start on it. Do you have references for how to do this? As I understand it, there are special Ethernet addresses that are "for bridges only -- do not forward" that are used to construct the spanning tree, etc. What is the "standard" algorithm used by bridges, etc.? After a quick search on google for "spanning tree" and "BPDU", here are some usefull links: http://www.ece.wpi.edu/courses/ee535/hwk96/hwk3cd96/sef/sef.html http://www.synapse.de/ban/HTML/P_LAYER2/Eng/P_lay119.html http://www.ethereal.com/lists/ethereal-dev/199910/msg00070.html http://www.support.baynetworks.com/library/tpubs/html/router/soft1000/bridge /2950A-16.html Apparently there is an implementation in linux (look for the file net/bridge/br_stp_bpdu.c) and the "BRIDGE-STP-HOWTO" (http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/BRIDG E-STP-HOWTO.html) http://www.linuxhq.com/kernel/v2.3/patch/patch-2.3.47/linux_net_bridge_br_st p.c.html Patrick. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD Build status
Hi,
I have a patch against these warnings. They are the result of a function
being called with a pointer to a function rather than a string...
/otte/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/c-common.c:1655:
warning: passing arg 1 of `warning' from incompatible pointer type
/otte/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/c-common.c:1655:
warning: passing arg 1 of `warning' from incompatible pointer type
/otte/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/c-common.c:1678:
warning: passing arg 1 of `warning' from incompatible pointer type
/otte/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/c-common.c:1678:
warning: passing arg 1 of `warning' from incompatible pointer type
The patch:
--- c-common.c.orig Mon Nov 1 13:41:09 1999
+++ c-common.c Sat Apr 8 06:32:52 2000
@@ -1652,7 +1652,7 @@
/* There should be an int arg to control the string arg. */
if (params == 0)
{
- warning (tfaff);
+ tfaff ();
return;
}
if (info-first_arg_num != 0)
@@ -1675,7 +1675,7 @@
/* There should be an unsigned char * arg before the string arg. */
if (params == 0)
{
- warning (tfaff);
+ tfaff ();
return;
}
if (info-first_arg_num != 0)
Should I just send a PR ?
Patrick.
c-common.c.patch
Integrating QMAIL in the world
Hi, I have integrated the source of qmail so it can be built as part of the "world". I think that it would be nice to have an alternative for the mailer package to be built as part of a make world. What I would like to do is upgrate the "NO_SENDMAIL" variable to a "MAILER_SYSTEM" variable, which could be set to "SENDMAIL" (default), "NONE" or "QMAIL". The advantage would be that we can have a fairly decent qmail configuration using the standard make world feature. Is there any interest in that kind of work ? Patrick. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Integrating QMAIL in the world
From: "Jon Parise" [EMAIL PROTECTED] On Sun, Apr 09, 2000 at 02:44:25PM -0400, Patrick Bihan-Faou wrote: I have integrated the source of qmail so it can be built as part of the "world". I think that it would be nice to have an alternative for the mailer package to be built as part of a make world. I don't recall the particulars (it's been a while since I've managed a qmail installation), but aren't there issues with qmail's distribution license that would make integrating it into the build tree illegal? I will contact DJB and find out if this is OK with him. After reading his "license" page, I come to the conclusion that it is a matter of obtaining is approval. He wants to ensure that qmail IS qmail no matter how and where it is installed. As a side note, I don't think it's all that good of an idea to add another MTA to the build tree, but I'm sure others will raise a more substantial argument than I could. Well, qmail is a fairly popular alternative to sendmail. It is supposedly more secure, and definitely easier to configure. I use it exclusively and it would be a lot nicer for me to have it included in the base distribution of FreeBSD. I am sure that other people feel the same. My intent is NOT to start a flame war on MTA's. If nobody is interested and/or the FreeBSD team does not want it, then it will not be included in the tree. It's that simple. I remember some while ago some threads going wild on the subject of MTA. The only reason why I am posting this is that I did the work for some other project I am involved in, and if it can help others, then I'd rather share it. Patrick. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Integrating QMAIL in the world
- Original Message - From: "David O'Brien" [EMAIL PROTECTED] On Sun, Apr 09, 2000 at 02:44:25PM -0400, Patrick Bihan-Faou wrote: I have integrated the source of qmail so it can be built as part of the "world". I think that it would be nice to have an alternative for the mailer package to be built as part of a make world. ... Is there any interest in that kind of work ? I'd say probably not. Peter Wemm is working on kicking Sendmail out of the base system and replacing it with a very simple piece that can do local mail delivery and outgoing SMTP to a relay host -- these are the minimal operational requirements. Then people that are running a mail server could install either the Sendmail, Postfix, Qmail, Zmail, etc... MTA ports. Sounds like a great idea. The reason why I am doing this is because I DONT want sendmail. The solution that is being implemented sounds like the best way to approach this. Thread closed ? Patrick. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mandating USA_RESIDENT
Hi, If we are changing the meaning of "USA_RESIDENT", could we replace it by something else completely. I know that the USA are the center of the universe ;-), but... It seems to me that a things progress, the crypto regulation gets more complicated everyday. Why not have a "CRYPTO_COUNTRY" variable that could be set to "USA" "FRANCE" "CANADA" or "other" based where you live and weither special consideration must be taken relative to the crypto code ? Then as part of the build process, automatically create specific variables for RSA or other stuff as they show up: CRYPTO_RSA="RSAref" or CRYPTO_RSA="rsa" or CRYPTO_RSA="none". This can be done by a little bit of shell script easily. The other thing that could be set based on the CRYPTO_COUNTRY code is where to get the FreeBSD crypto related source from. Finally, the current "USA_RESIDENT" variable can then be generated automatically and with good confidence that it is set to a correct value (for the ports or source that still relies on that). OK, it may be overkill for what we need now. So if it looks too much like a bad idea, kill it now. Patrick. - Original Message - From: Sheldon Hearn [EMAIL PROTECTED] Newsgroups: list.freebsd.current Sent: Tuesday, January 18, 2000 8:02 AM Subject: Re: Mandating USA_RESIDENT On 18 Jan 2000 03:03:09 PST, Satoshi - Ports Wraith - Asami wrote: Maybe it's better to make it an error to not specify it (yes, killing "make world" and stuff, that's what UPDATING is for). There's no better time for doing so than prior to 4.0-RELEASE. :-) Does sysinstall set this one? If not, it should. Then we can stop worrying about it. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Make world break on openssl...
Hi, this is probably not news, but here is what I get. I tried with both USA_RESIDENT=YES and no USA_RESIDENT defined... The code has been CVSuped on tuesday Jan 18 2000 around 2am EST. cc -O -pipe -DMONOLITH -DNO_IDEA -I/usr/src-freebsd-4.x/secure/usr.bin/opens sl -DRSAref -I/usr/obj/usr/src-freebsd-4.x/i386/usr/include -o openssl apps.o asn1pars.o ca.o ciphers.o crl.o crl2p7.o dgst.o dh.o dsa.o dsaparam.o enc.o errstr.o gendh.o gendsa.o genrsa.o nseq.o openssl.o pkcs12.o pkcs7.o pkcs8.o req.o rsa.o s_cb.o s_client.o s_server.o s_socket.o s_time.o sess_id.o speed.o verify.o version.o x509.o -lssl -lcrypto -L/usr/local/lib -lrsaref speed.o: In function `speed_main': speed.o(.text+0x60a): undefined reference to `RSA_PKCS1_RSAref' /usr/local/lib/libcrypto.so: undefined reference to `ERR_load_RSAREF_strings' *** Error code 1 Stop in /usr/src-freebsd-4.x/secure/usr.bin/openssl. *** Error code 1 Stop in /usr/src-freebsd-4.x/secure/usr.bin. *** Error code 1 Stop in /usr/src-freebsd-4.x/secure. *** Error code 1 Stop in /usr/src-freebsd-4.x. *** Error code 1 Stop in /usr/src-freebsd-4.x. *** Error code 1 Stop in /usr/src-freebsd-4.x. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ipfw optimizations
Hi Luigi, i am looking at (minor) optimizations of the ipfw code in order to reduce the running time in the common cases. I have a few ideas (mostly along the lines of optimizing for the most commonly-used rules). An obvious candidate is the 'match all' rule (all from any to any), but can people suggest other common usage of rules in ipfw ? One of the things I would do to optimize ipfw is: - instead of keeping one list with all the rules, split the list (the internal one) by interface and by direction (one list for ed1 incoming, one list for ed1 outgoing, etc.). - then eventually you could be doing the same thing by IP protocol number, but it might not be worth it (with regard to the amount of work required). I think that it is a better way to optimize ipfw than optimize the "match all" rule, since in any security conscious this is likely to be a deny rule, and who cares if it takes a little longer to deny a packet ? My goal usually is to accept legitimate packets as early as possible, reject really obvious stuff also fairly early and then handle the less common stuff. At last there is my match all deny rule, but it does not get exercised that often. One advantage of having a compiled ruleset for each interface would speed up quite a bit the processing by not going over rules that are not applicable. I looked once at doing that on the 3.x-STABLE ipfw, and even if it did not seem to be *too* complicated to do, I did not have the time to go further. Any thoughts ? Patrick. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ipfw optimizations
Hi, One of the things I would do to optimize ipfw is: - instead of keeping one list with all the rules, split the list (the internal one) by interface and by direction (one list for ed1 incoming, one list for ed1 outgoing, etc.). I often do this manually in long rule sets by using things like ipfw add 1000 skipto 1 from any to any via de0 ipfw add 1001 skipto 2 from any to any via de1 ... ipfw add 1 skipto 15000 from any to any in via de0 #process outbound on de0 rules here ipfw add 15000 blah blah # processing inbound on de0 rules here [...] Anotherwords, don't burden the ipfw with code that can easily be done by an intellegent user, and some more examples/documentation... Yep, and there happens to be a rule that you would like to be tested in every case, but you don't want to test it at the begining (before the switch) but sometime in the middle. With your scheme (which is the only reasonable one currently), you have to duplicate that rule for every branch. This is fine, but if now you need to modify the rule somewhat, don't forget to modify it everywhere. This can rapidly become a maintenance nightmare. What I was proposing is that the per-interface switch be done implicitely by ipfw. So if you do: ipfw add allow ip from joe to bob via de0 ipfw add allow ip from arthur to joe in recv de0 ipfw add allow ip from john to any You get the proper rule tree generated: - ed0 RX: allow ip from joe to bob allow ip from arhur to joe allow ip from john to any - ed0 TX: allow ip from joe to bob allow ip from john to any - ed1 (TX or RX) allow ip from john to any By the way, in terms of optimization you will save: - 2 * number of interfaces rules (the skiptos) that have to be tested for most packets - 2 tests for each rule after (you don't need to retest the interface nor the direction, it has been. If you go further in that logic and implement a per protocol switch, you reduce the number of test even more. To answer a previous question about the number of interfaces, I use FreeBSD as a gateway with 2 ethernet interfaces and 3 tunnel interfaces (ipsec) to remote locations. I guess that most cases where you really worry about ipfw is in gateways where a minimum of 2 interfaces seems reasonable. Again, I am not saying that you can not implement a similar behaviour with ipfw as it is now, I am just saying that if you want to optimize it, you want to reduce the number of test you perform for each rule. What I am proposing is one way of doing it (and as a side effect, it makes managing a tree like set of rule easier). Patrick. matched already) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ipfw optimizations
(don't you love all that quoting...) I agree that having a `switch' type of rule for selecting interfaces would be a reasonable gain of efficiency (but then again.. how many interfaces is one using!) It doesn't matter, it has to do the lookup on a per-interface basis. On my firewall box, I have 11 interfaces. Two ethernet, one loopback, 4 slip, and 4 tunnel. i meant, if you only have 2-3 interfaces which are used 90% of the times, then you really have 1-2 extra rules to look for. But, in any case, it seems reasonably clear that a 'switch' statement would simplify rule writing in a number of situations, and i agree with Rod that the way ipfw does (having all rules potentially applicable for all cases) is very very flexible and probably more convenient than per-interface lists in many cases. Yes I agree, I love ipfw functionality. You were asking for ideas on how to optimize ipfw. What I suggested is that in its INTERNAL representation of the rules, ipfw could split the rules on a per interface/direction basis. This means that you will not look at the rules that are known to not apply to your interface AND direction, hence saving some time. Again I am not asking for modification of the "user interface" of ipfw which is nice and to the point. As you and Rod mention, the ability to have rules applicable to all interfaces in one shot is great. What I was thinking about is when you build the "per-interface" list of rules, use what is provided in the interface part of the rule to determine where it belongs: ipfw add allow ip from joe to bob in recv ed0 = this rule is to be added only in the inbound list for interface ed0 ipfw add allow ip from joe to bob via ed0 = this rule is to be added to both inbound and outbound lists for i/f ed0 ipfw add allow ip from joe to bob = this rule is to be added to the inbound and outbound lists for all i/fs In the future we could also use negative logic to add a rule to all interfaces except the one mentioned... Also as I said earlier, you don't have to do anymore interface checking when it is implemented this way. The fact that you use such or such list is enough. Also to respond to some comments from Rod, this scheme duplicates the rules, but it does so behind the scene, so it does not add more complexity to the way you configure ipfw. Actually it remains completely compatible with the current behaviour of ipfw. Is that SO unreasonable Patrick. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ipfw optimizations
No, this is completly reasonable now that I understand what it is your proposing. Even the memory footprint is minimal if pointers to the actual rules is all we store in the per interface list, my largest set duplicated over 8 interfaces would only be 3200 rules. Stored as pointers to rules this would be all of 12.8kbytes, certainly not enough to worry about :-). Good I felt like I was stupid for a while here ;-) Come up with some patches and I'll be glad to test and review them for you... I'll get on that as soon as I am done with that paying job I am doing now :(. Which probably means sometime next week. (don't you hate to have these bills to pay ?) Patrick. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
Hi, Maybe I am wrong, but it seems to me that there is already quite a bit of IPv6 and IPSec stuff in the tree. Most of the kernel stuff is there (albeit seriously lacking documentation). To me this is not *too* critical right now. I see the point for the research community though. Also, regarding what makes a *.0 release, I would say stability is the main thing. More complete features will come with the .1 .2 etc. releases. Look at the 3.x history: we just got some major features in the late 3.x (netgraph in 3.4) this does not mean that 3.0 was a bad release. If I can be sure that the IPSec and IPv6 userland stuff and documentation will be in 4.1 for sure, I would advocate for the feature freeze now. There are quite a few things that are good in 4.0 and that I really want to use in my production boxes (the new ata driver for example). To me getting what is already there in a *blessed* form is what is important. Rather than a full, complete IPv6 feature in 4.0, I would rather see that the 4.x-STABLE branch keeps track of the Kame mods in it by default and soon so that when 4.1-RELEASE is around IPv6 is in. Does that make sense ? Patrick. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Status of the netatalk stack
Hi Julian, the kernel code for appletalk is 'out of date' but it is also somewhat modified.. If you want to work with it, let me know and I can help as I did the original integration into our tree, Well I would definitelly appreciate a quick summary of the changes that you did to integrate the netatalk code. A couple of pointers on what to look for would be really good to! Anyway, I will try to get working on this during the hollidays or maybe early in january. a+ Patrick. -- www.mindstep.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Status of the netatalk stack
Hi, I was looking at the netatalk package and the appletalk support in the kernel source code and I realized that they are based on the same code originally (the code from netatalk). The kernel code however is quite out of date from what can be found in the netatalk-asun package. I was wondering if anybody is planning on integrating the latest changes ? If not is it something that I should undertake ? Are there any major reasons why the code in freebsd should be left alone ? PS. I cross-posted in current and stable because it affects both stream in the same way, however I guess the discussion should be kept in "current", so please try to reply to the correct address. Thanks. Patrick. -- www.mindstep.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make.conf options (was Re: package-like feature for the base distrib (was Re: FreeSSH))
Hi, From: Cy Schubert - ITSD Open Systems Group [EMAIL PROTECTED] I was not talking about things that constitute the "real" core of the distribution (kernel, basic libraries etc.). I was more thinking about "userland" stuff that is included in the distribution but might not be required by everybody. Sendmail for example is something I don't want since I user qmail. However I have to remove it by hand... Other examples are bind or perl. You don't need to install them. Just put these in make.conf. NO_SENDMAIL= true NOPERL=true NOGAMES= true It might be a good idea to support NONAMED, NOUUCP, and NONFS, defines in make.conf. Since some like to use Qmail, Postfix, SSH, and Kerberos V, like BUILD_PORTS='postfix ssh krb5 XFree86' in make.conf would fetch new copies of distfiles (if you don't have them), de-install old versions, build and install the listed ports each time a make world is performed. This is going in the right direction, but here is a question (and I don't have the answer). Is it so much more easier to create new compile time directive than to go the extra step and use packages where they are available ? For example "bind8" is available as a package. Why not have the base install process use that instead of using its own source ? After all the package system is good, and we should capitalize on it. For things that don't have an equivalent (yet) in the ports, then there are 2 approaches: - the component is "optional enough" that it could be made as a package - or it is really required, in which case it belongs to the core installation. By optional enough, I mean something that: (this is likely not complete) a/ is not required by everybody (UUCP, YP) nore by the kernel to run properly b/ does not rely on other kernel components to be built properly c/ ... Again, I think that "sendmail" definitelly falls in that category as well as "bind". As far as the BUILD_PORTS variable. This is a great idea... Again why not take it to the next level which could be to have a new "target" in the ports' makefile: something like "make pkg_update" which would go and build/install the new version of all the installed packages/ports ? If I can help moving things in that direction, I will hapily land a hand... Patrick. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: package-like feature for the base distrib (was Re: FreeSSH)
Hi, From: Pierre Beyssac [EMAIL PROTECTED] There are a _lot_ of pitfalls to this kind of approach, as I have discovered using Linux Debian. This would probably open a can of worms you have no idea of. IMHO, the single biggest mistake in Debian is the all-encompassing package system which can make your life miserable in no time. [...] I was not talking about things that constitute the "real" core of the distribution (kernel, basic libraries etc.). I was more thinking about "userland" stuff that is included in the distribution but might not be required by everybody. Sendmail for example is something I don't want since I user qmail. However I have to remove it by hand... Other examples are bind or perl. Basically I think anything that has an equivalent and/or an alternate installation method in/via the "ports" system should be registered with the rest of the packages. And, IMHO, package handling for general-purpose applications and package handling for the core system are a very different problem and should be handled in very different ways. Agreed. This is the key. The package/ports system is really great as is. The split between the distribution and the packages/ports is sometime annoying. Again I think this mostly concerns "userland" features that are not required for the core of FreeBSD. Patrick. -- MindStep Corporation www.mindstep.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
