Re: 4.0 code freeze scheduled for Jan 15th
On Thu, Jan 06, 2000 at 02:14:04AM -0800, Julian Elischer wrote:
> Darren Reed wrote:
> >
>
> >
> > For what it's worth, I think releasing 4.0 *without* IPv6 support
> > is a mistake. Why ? Because in < 12 months FreeBSD 5.0 will be
> > released *with* IPv6 support (I'd count IPv6 as being a big enough
> > change to signify a major release number change). If that doesn't
> > happen, then FreeBSD is chasing the wrong goals, IMHO.
> >
> > Personally, I think the timeline laid down - 25(?) days from now
> > until 4.0 release is too aggressive. Given that the announcement
> > (to me) seemed to be rather autocratic and possibly driven by
> > marketting factors ("we need 4.0 out now regardless" ?) than by
> > the general stability and maturity of -current. Well, that's the
> > impression I get from an announcement encouraging people to do
> > heavy testing in the next 10 days. I would encourage Jordan and
> > others to have a rethink about the timeframe for 4.0 and what plans
> > they have for it feature wise.
>
> I agree with this..
> I think that 4.0 is clsoe but it's just not there yet.
> I think it needs IPV6 to have reached a better milestone, and certainly
> the stuff that warner is doing (and others) needs to be a little
> further down the track.
In my opinion, whether the present plans for 4.0-RELEASE is
appropriate or not somewhat depends on what the further plans are for
the release engineering.
I believe putting down RELENG_4 without having a finished IPv6 and
functional laptop support (I'm not sure what state this is in right
now) would be a bad idea.
> I think we should layout a plan of everything that everyone is
> working on and try find a natural inflection point. I reallu thing
> that IPV6 is too important to make a release with it "half"
> implemented.
If somebody is up to organizing it, it would be nice to have an
overview of what everybody would like to put in before we decide to
put down a branch. However, given how much variance most of us has in
how much effort (or at least results) we're able to push into FreeBSD,
it is somewhat hard to create clear lines for things, so we might have
to be satisfied with lining up some of the most important things.
Eivind.
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
On Thu, Jan 06, 2000 at 09:09:22AM -0700, Warner Losh wrote: > In message <[EMAIL PROTECTED]> Eivind Eklund writes: > : I believe putting down RELENG_4 without having a finished IPv6 and > : functional laptop support (I'm not sure what state this is in right > : now) would be a bad idea. > > The laptop support is approx that of 3.x. The fe device is no longer > supported as a pccard. The sn device has been added. The YE_DATA > floppy device isn't supported, but could be if some is motivated to > fix it. There may be a few lingering hot plug issues in the old > code's migration to newbus. How much benefit would you be getting by having 4.0 ship with newcard instead of what's there now? E.g, by having 4.0-PAO relate to newcard rather than what's in presently? Eivind. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
NFS HEADS UP (was Re: cvs commit: src/sys/nfs nfsm_subs.h xdr_subs.h)
On Thu, Aug 19, 1999 at 07:50:13AM -0700, Peter Wemm wrote:
> peter 1999/08/19 07:50:13 PDT
>
> Modified files:
> sys/nfs nfsm_subs.h xdr_subs.h
> Log:
> Convert all the nfs macros to do { blah } while (0) to ensure it
> works correctly in if/else etc. egcs had probably picked up most of the
> problems here before with "ambiguous braces" etc, but this should
> increase the robustness a bit. Based on an idea from Eivind Eklund.
When I tested this, I got significant binary changes after changing
the macros to be . Writing a couple of test programs, I was not able
to get binary changes without actual semantic changes - the optimizer
optimize away do { ... } while(0); just fine. I didn't have any
testbed for NFS, which was why I didn't commit similar changes myself.
Interpretation: NFS is likely to be different now than it was before
these commits. This hopefully mean less bugs, but we might also have
had bugs cancelling each other and 'mystery fixes' that no longer
work. If you get strange effects in NFS in the upcoming time, you
might try flipping this commit.
I still think the change is a good and necessary one.
Eivind.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
People getting automatically unsub'ed from -arch
[Mayhaps too many Cc:'s kept in order to reach relevant audience] On Sun, Oct 10, 1999 at 02:57:55PM -0600, Nate Williams wrote: > > I Can't believe this email only produced TWO responses! > > I would have thought that this wouldhav brought out the chainsaws! > > Maybe no-one is listenning on 'arch' any more, or maybe 'arch' doesn't > > work? (the only responders got it via 'core') > > Interesting. It appears that somehow I got 'unsubscribed' from arch. > Not sure why, but in May I was subscribed, but I'm no longer subscribed. > > Did everyone get unsubscribed when it went idle? Not *everybody*, at least - my subscription has kept. I do not know of any mass-unsubscription. Eivind, ex-moderator and now pseudo-moderator of -arch. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/libexec/uucpd uucpd.c
On Mon, Nov 08, 1999 at 01:04:29PM +0200, Valentin Nechayev wrote: [Regarding a change to UUCP to have it log the username when the password entry fails] > > I don't have any religious feeling about this change, and I'm willing > > to back it out and keep it as a local change again (the way it has > > been for a year or so). I just thought it would be considered an > > improvement for other users, too. > > Possibly it should be turned off by default and turned on in config. I do not have making improvements to UUCP as a high priority for my FreeBSD work, and I'm short on time, so I can only offer you the following options: (1) Write up diffs to support this, and I'll review them (and commit them if they are OK). (2) Keep the change in there the way it is (3) Back the change out I don't want to volunteer more of my time to even do further discussion - having this change in FreeBSD is that low priority to me (I have a bunch of things to do with FreeBSD, and spending time on this means that less time go to other things). Eivind. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: repeatable crash in -current (softupdates, NFS)
On Sat, Nov 27, 1999 at 10:26:15AM -0500, Viren R.Shah wrote: > > I'm running a -current system from Nov 26th (approx 4am EST). > > I can currently reliably crash the system by doing: > > ln -s /home/users/vshah/public_html/index.html /home/users/vshah/index.html > > > The crash only works when I do it on a NFS mounted filesystem. I'm > using NFSv2/UDP. The server is a 3.2-STABLE FreeBSD box, running > softupdates on the exported filesystem. I just checked that local > filesystem on the server, and it is a 100% full. Can this just be put > down to the known "softupdates full filesystem bug"? > > [BTW: the server hasn't crashed, it's only the FreeBSD client that > crashes] I *think* I know what this is due to - please upgrade src/sys/nfs/nfs_vnops.c to revision 1.146 (which I just committed) and try again. My bad. Eivind. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: repeatable crash in -current (softupdates, NFS)
On Mon, Nov 29, 1999 at 01:52:29PM -0800, Matthew Dillon wrote:
> :
> : Eivind> I *think* I know what this is due to - please upgrade
> : Eivind> src/sys/nfs/nfs_vnops.c to revision 1.146 (which I just
> : Eivind> committed) and try again.
> :
> :Tried it. Doesn't work. :-( It still crashes when creating a symbolic
> :link on a NFS mounted filesystem. [This is unfortunate in my case,
> :as it prevents me from running Netscape -- the home dirs are NFS
> :mounted]
>
> Eivind, I'm not sure that change you made is legal. People use
> symlink creation the same way they use O_EXCL file creation - as a
> locking mechanism. In fact, in NFSv2 O_EXCL file creation is not
> atomic (I'm pretty sure) and symlink was the *only* method available.
The sum of the changes I made does not (or is at least not supposed
to) change the semantics of symlink creation. If you see some way the
semantics are changed, please tell me - that's an error.
> If you blow away the error you will probably break a good deal of
> third party code.
I haven't added anything to blow away the error - I've moved code that
already was there up before code I added that depended on the error
being the same as what was returned.
I've been peering over the code, and I am unable to find anything
wrong :-( I've also gotten panic information and symbol information
from Viren, but this hasn't made me any wiser - the failure was in
setlock (which seems to be an assembler symbol related to
simplelock()), but this isn't of much help.
The only idea I have for a flaw right now is that if newvp in
nfs_symlink can somehow be NULL in the non-error case, then my code is
in error. The following patch adds a test for this:
Index: nfs/nfs_vnops.c
===
RCS file: /home/ncvs/src/sys/nfs/nfs_vnops.c,v
retrieving revision 1.146
diff -u -r1.146 nfs_vnops.c
--- nfs_vnops.c 1999/11/27 18:14:41 1.146
+++ nfs_vnops.c 1999/11/29 22:51:12
@@ -1821,8 +1821,10 @@
if (error) {
if (newvp)
vput(newvp);
- } else
+ } else {
+ KASSERT(newvp, ("No vp in nfs_symlink"));
*ap->a_vpp = newvp;
+ }
VTONFS(dvp)->n_flag |= NMODIFIED;
if (!wccflag)
VTONFS(dvp)->n_attrstamp = 0;
If somebody can run this and tell me if they get this panic instead of
the old one, I'd appreciate it.
Eivind, who thinks this might indicate he will have to set up an NFS
testing environment :-/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: repeatable crash in -current (softupdates, NFS)
On Mon, Nov 29, 1999 at 11:56:31PM +0100, Eivind Eklund wrote: > I've been peering over the code, and I am unable to find anything > wrong :-( I've also gotten panic information and symbol information > from Viren, but this hasn't made me any wiser - the failure was in > setlock (which seems to be an assembler symbol related to > simplelock()), but this isn't of much help. Actually, this info was from Lester Igo, not Viren. Sorry for the misattributation. Eivind. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Killed Myself
On Tue, Nov 17, 1998 at 09:49:31PM -0500, HighWind Software Information wrote: > > After installing the recent libc_r and libc, I'm getting: > > ld.so failed: Undefined symbol "SYS_kldsym" in make:/usr/lib/aout/libc.so.3.1 > > I also get it sometimes when I link against libc_r. > > "SYS_kldsym" is always the thing I don't seem to have a definition for. > > This just started happening. UGH! If you do not know how FreeBSD works to a detailed enough level to NOT HAVE TO ASK THIS, then you should MAKE WORLD. You should NOT try to do incremental recompiles. That is reserved for those people that know exactly what they are doing. Sorry, but this is like taking a nail-gun and shooting from the hip towards the floor instead of actually bedning your knees, and then coming shouting 'My foot hurts! My foot hurts! What should I do?' Eivind. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Killed Myself
On Mon, Mar 08, 1999 at 05:59:05PM -0500, John S. Dyson wrote: > Eivind Eklund said: > > If you do not know how FreeBSD works to a detailed enough level to NOT > > HAVE TO ASK THIS, then you should MAKE WORLD. You should NOT try to > > do incremental recompiles. That is reserved for those people that > > know exactly what they are doing. > > And those who know exactly what they are doing still get zapped. Of course - but we know not to ask :-) Eivind. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FTP passive mode - a new default?
On Wed, May 26, 1999 at 07:54:03AM -0700, Jonathan M. Bresler wrote: > > > > Unless I hear unanimous fierce outcry against it, I'm strongly > > considering making FTP_PASSIVE_MODE obsolete by virtue of being the > > default for all tools/libraries which currently examine it. > > FTP_ACTIVE_MODE will be the new flag for toggling the previous > > behavior. > > > > Given the state of the Internet today, I think this is purely a > > sensible change in defaults. Comments? > > > do any apps check for FTP_ACTIVE_MODE? > are we going to apply patches to each app to check for this > and maintains those patches over the course of time? > > seems to be a change without commensurate benefit.it will > confuse some, suprise others and doesnt seem to offer > substantial benefit. It has the (large!) benefit of NATed[1] and firewalled users getting a working setup at once. I'm in favour. [1] Those using natd/ppp -alias will get this already, due to a protocol translator in libalias. Alas, this does not combine with firewalls on the NAT machine unless somebody choose to activate the code I added to libalias to punch 'holes' in ipfw. Eivind. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Automated debug sanity checkers
On Fri, Jan 15, 1999 at 09:12:07PM -0800, Archie Cobbs wrote: > I was thinking about the DIAGNOSTICS replacement macros and > had a random thought... > > Suppose you're sitting in front of a ddb (or better yet gdb) prompt > because your kernel has just crashed due to who knows what reason. > What do you do to debug this? You start looking at variables, > memory, etc for anything funny going on. > > For example, several times we've spent hours going through a crash > dump to find, for example, that a process was on two queues, or > some mbuf was mangled, etc. > > The thought is that it would be really easy to help automate this > process, by doing the following: > > 1. Define a new kernel option INCLUDE_SANITY_CHECKS (or whatever) INVARIANT_SUPPORT. Hey, I just happen to remember that somebody added this a couple of days ago - hmm, could it have been me? :-) > 2. When this is defined, all the various FreeBSD kernel > submodules (VM, networking, device drivers, etc) would > include a function that exhaustively runs sanity checks -- > ie, validations that all the assumptions in the code are true -- > for that particular submodule. This means checking all queues, > flags, whatever. Ie, invariants. > 4. The function is linked into a linker set SANITY_SET(...) or whatever I've not thought of that - that may be a good idea. > Then by simply calling this function from the debugger you can > much more quickly narrow down on the problem (and hopefully fix > it before you get tired and go to sleep :-) > > Moreover, since the function is running post-mortem, it can do > very detailed checks that would otherwise take way too long. > E.g., check every mbuf, every queue entry, check the filesystem, > etc. Basically a "fsck" for the kernel memory. You do not only want to call this at post-mortem. You often want to selectively use this while the kernel is running. Example: At one point (a year and half or so ago), I was debugging the tty driver in bisdn. For some reason, it was crashing in various ways at various times, with no sane reason - just garbage data. I spent quite a bit of time looking at this, finding no reason for the faults - they "just happened", taking on average perhaps 4 hours hours under load to trigger. As I was getting more and more frustrated with attempting to shotgun debug this, I went back to my normal mode of development - I wrote invariants for all data structures in the vicinity. When I added an invariant for the clist structures (and check of it all over the place), I found that my "crash" (now an invariant incorrect panic) time went down to two minutes - and that it was always the same way, with the same stack backtrace, instead of crashing at various random points. The reason for the bug turned out to be that both I and the implementor of the driver had missed the change of spls from levels in BSD4.4 to masks in FreeBSD. After I had seen the invariant failure, I could see that something was being interrupted between two spls - and after 3 minutes of reading the FreeBSD manpage and three lines of changes I had something that worked. That driver had been non-functional for at least three releases of bisdn (and the userland code to handle it was not even there, which I expect was due to this). I further expect that somebody had tried pretty hard to debug it, as they had spent the time to actually write it. The fact that I (which at that point had little experience with the FreeBSD kernel) was able able to debug that in a couple of hours where others had used more time and failed before me show some of the power of invariants for finding obscure bugs. I would like to have invariants available for all significant data structures, and I'm planning to write them up as I get time for it. > Is this something that people would be motivated enough to make > as "official" FreeBSD kernel good housekeeping policy? I suspect a large number of us will use it, making it likely it will sort of maintain itself. Eivind. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: "JAIL" code headed for -current.
I'm moving this to FreeBSD-arch, due to taking the discussion quite a bit in that direction. On Wed, Jan 27, 1999 at 11:44:35AM -0800, Sean Eric Fagan wrote: > In article > <29763.917434096.kithrup.freebsd.curr...@critter.freebsd.dk> you > write: > >The biggest impact of this is a new argument to the suser() call > >all over the kernel: > > > > suser(NOJAIL, bla, bla); > >or > > suser(0, bla, bla); > > Oh, goody, more gratuitous incompatibilities with everyone else. suser() is not generally compatible; the return value has different (opposite) meanings in different OSes. I do, however, think there are a couple of problems with the implementation as outlined above, even if we ignore any incompatibility arguments: 1. It is insecure in the face of changes. Any security policy should default to deny; the above policy default to 'accept'. Later kernel mods are likely to introduce security holes. 2. If more similar authentication mods are made, they also require changes all over the system. 3. Policy is distributed everywhere, instead of a being concentrated in one place, which makes it hard to verify. I have been planning some changes for much of the same purpose. My approach is to introduce a string identifing each context for suser(), to allow people that want to hack on the authentication system an easy place to start from. In a similar setting before, I've successfully used a hierarchical system, going from less to more specific context specification. Example: a chflags in an FFS would be something like "fs/chflag/ufs/ffs" while in an lfs, it would be "fs/chflag/ufs/lfs". I've not thought much about the backend for this - if it is to be used in general (instead of just as a good starting point for people that want to do some authentication hacks on their machine), there should probably be some way to express interest in just some of the nodes of the tree the different authentication types form, and caching to avoid string parsing. If phk would be satisfied with a slightly hackish solution for the time being, we could introduce the above, and just use string compares for his acceptable cases for the time being. This could be done as a binary tree, so it wouldn't be quite as expensive as it sounds. Context for the people not having done their own source investigation of credentials use: We have approx 180 root checks using suser(): eivind(bitbox)--% glimpse -y suser | wc -l 185 We have approx 90 checks for root that are NOT done using suser(), rather using explict comparisons with 0: eivind(bitbox)--% glimpse -y cr_uid | grep 0 | wc -l 94 Another interesting statistic for root mods probably is the number of cr_uid references in the kernel (all of these should be inspected): eivind(bitbox)--% glimpse -y cr_uid | wc -l 283 If you're thinking of a full-blown look at capabilities, cr_gid is used 28 places, cr_groups 60, and cr_ngroups 52. Given the relatively low number of credentials uses (less than 400), it shouldn't be more than a couple of evenings worth of work to collapse it all back to a set of function or macro calls, creating a much more suitable environment for capabilities hacking. Eivind. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: btokup().. patch to STYLE(9) (fwd)
On Fri, Jan 29, 1999 at 12:05:04PM +0200, Sheldon Hearn wrote: > > > On Fri, 29 Jan 1999 20:01:23 +1030, Greg Lehey wrote: > > > > I can't imagine how unnecessary parens are going to improve > > > "readability" for anyone who knows his/her operator precedence. > > > > What about the others? > > I'd like to know that people who don't know operator precedence are > leaving the kernel code alone, eh? :-) I know my operator precedence. I still often find that using extra parentheses make code more readable. I don't do it in FreeBSD, but I regularly use more parentheses than strictly necessary for non-FreeBSD code. I also am in favour of the change to style(9). Eivind. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cleanup of rc.conf ( -4.x )
On Mon, Feb 08, 1999 at 08:14:55PM -0800, Matthew Dillon wrote: > This does not make any operational change except to get rid > of the $conf_dir junk from rc.conf, which I originally put > in to try to bootstrap rc.diskless. > > A much better way to do rc.diskless was suggested to me, > which I'm going to implement. It involves retargeting > the /conf/ME softlink by mount_union'ing a small MFS Union mounts do not work, and I believe they are some distance from working (unless you have better patches than I do, of course). Eivind. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: 3.1?
On Tue, Feb 09, 1999 at 08:34:28PM -0500, Gary D. Margiotta wrote: > Hello, > > Don't mean to be a pest, or a PITA by asking this, but is the 3.1 branch > still scheduled for the middle of this month? I haven't seen much on the > list recently about it, but probably haven't been paying enough attention > to it tho... Thanks! There won't be a 3.1 branch - however, 3.1-RELEASE is still scheduled for the middle of this month :-) Eivind. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Wrong things posted to -current (was Re: Need Help)
On Wed, Feb 10, 1999 at 12:58:39PM +0100, andrea wrote: > HI > > I have a trouble with FreeBSD 2.1.5 This an example of the type of question one DOES NOT ANSWER in freebsd-current. Instead, send a polite note to the poster telling him to send his question to questi...@freebsd.org, along with a quick answer (if you know it). curr...@freebsd.org presently sees more traffic than hack...@freebsd.org - it is filled with all kinds of not-really-related-to-current material. Please take care to keep our signal-to-noise ratio good - including not answering bad postings, and not posting technical questions to curr...@freebsd.org (they belong in hack...@freebsd.org and questi...@freebsd.org, depending on what level the question is at). Eivind. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD Crippleware (was Re: adding DHCP client to src/contrib/)
On Thu, Feb 11, 1999 at 09:46:06AM -0800, Steve Kargl wrote: > (2) never question the intentions of a committer particularly > on a mailing list. Do NOT follow this rule. We should all be questioned. Eivind. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: /etc/defaults/rc.conf
On Wed, Feb 17, 1999 at 06:15:06PM +1030, Greg Lehey wrote: > On Tuesday, 16 February 1999 at 9:24:31 -0800, Jordan K. Hubbard wrote: > >> If I have a /etc/defaults/rc.conf, then my /etc/rc.conf won't be consulted. > > > > Wrong. You need to read just a bit FURTHER into that file before > > jumping to such conclusions. :-) > > Been there, done that. Next thing is to write a book about it. Can I > hope that it won't change again this year? You can _hope_. Eivind, who has a number of things he would like to see be different in the rc system (including rc.conf) - see http://www.freebsd.org/~eivind/newrc.html for a set of requirements and a couple of thoughts. Missed requirements are welcome. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic: zone: entry not free
On Tue, Feb 23, 1999 at 10:59:39AM +0100, Jos Backus wrote: > On Tue, Feb 23, 1999 at 12:09:03PM +0300, Dmitrij Tejblum wrote: > > Inline functions in vm/vm_zone.h depend on INVARIANTS. These functions > > used in msdosfs and in other parts of the kernel. > > OK, I see. > > > > How does one add INVARIANTS support to modules? > > > > You could add -DINVARIANTS to CFLAGS in sys/module/msdosfs/Makefile. > > You better just link msdosfs statically, or remove INVARIANTS from your > > kernel. > > I'll try this tonight, thanks. > > > That is, INVARIANTS in kernel incompatible with dynamic loading. > > Somehow this strikes me as a Bad Thing... It _is_ a bad thing. I've been pondering what to do with the intrusive invariant checks - make them dependent on INTRUSIVE_INVARIANTS, perhaps? That would still make some KLDs incompatible with INTRUSIVE_INVARIANTS, but that is probably the best we can do. Eivind. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic: zone: entry not free
On Tue, Feb 23, 1999 at 05:08:57PM +0100, Jos Backus wrote: > On Tue, Feb 23, 1999 at 04:16:26PM +0100, Eivind Eklund wrote: > > > Somehow this strikes me as a Bad Thing... > > > > It _is_ a bad thing. I've been pondering what to do with the > > intrusive invariant checks - make them dependent on > > INTRUSIVE_INVARIANTS, perhaps? > > Depends on how dangerous these invariant violations are, I would think. > Iow, do they justify a panic()? IMO, any invariant violation justifies a panic(). Otherwise, people would not pay heed to them. Invariant violations are pretty serious. However, my opinion is also that invariant checks should be non-intrusive - ie, they should not change the normal code path, only add extra checks. A couple of the invariants we have modify the behaviour to make it possible to check for things, and this should be separate from the ones that doesn't modify the behaviour beyond adding checks. Eivind. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: mount -o union broken recently?
On Fri, Feb 26, 1999 at 09:16:44PM +0100, Luigi Rizzo wrote: > (about union mounts on 3.1 not returning all files with an 'ls' in 3.1 > while it did in 3.0) > > > Is it sorrect that this magic is implemented in sys/kern/vfs_lookup.c? > > The odd thing is that AFAICS no-one has made significant changes to > > this code. > > i just experienced the above today while trying diskless, and while ls > only seems to return the entries for the topmost directory, files are > accessible if you know the name. no idea if this is of any help. > > on a related subject; i noticed that using mount_null on a directory > with device entries (e.g. still in the diskless case, say /foo/dev is > an mfs partition with device entries, and i do a mount_null /foo/dev > /dev ) causes very bad effects such as crashing the system when i > start X. ideas about this as well ? Yes. NULLFS mounts do not work, due to a combination of aliasing problems and locking problems. There is a preliminary patch at http://www.freebsd.org/~eivind/FixNULL.patch that I believe fix the aliasing problems, and some of the locking problems, but not all. Using nullfs with this works somewhat, but sometimes get locks screwed up (which result in access to one file just hanging). Eivind. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
*** HEADS UP *** rc.conf changes (security)
After discussion with obrien, jhb, and dwithe (and non-protests from the other committers present), I'm changing the defaults for remote services in /etc/defaults/rc.conf to the least dangerous configuration, and making sysinstall write out overrides for the variables to their former default values in /etc/rc.conf upon install. This means that anybody upgrading /etc/defaults/rc.conf needs to add the following lines to rc.conf if they want to have the same setup afterwards (unless the variables already are set, of course): # Enable network daemons for user convenience. inetd_enable="YES" portmap_enable="YES" sendmail_enable="YES" (Heads up is over - more change detail below.) This change might seem a little counterintuitive (given that /etc/defaults/ are for defaults, after all) but seems to be the best compromise for both getting the functionality jkh wants (freshly installed boxes have active daemons, so users don't feel they have a lot of extra hassle to get things up and working like they are used to on other Unixen), and give FreeBSD a default secure config, meaning the insecurities stand out. I assume those of us that do new installs without using sysinstall know FreeBSD well enough to be able to handle turning those daemons on again if we want them ;) BTW: Keep me in the Cc: list, please - I am not subscribed to -current (or any other FreeBSD mailing list) at the moment. Eivind. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pppd + natd (was: Re: some bugs in natd.8)
On Thu, Mar 13, 2003 at 05:43:58PM +0200, Ruslan Ermilov wrote: > On Thu, Mar 13, 2003 at 07:24:58AM -0800, Eivind Eklund wrote: > [...] > > > Okay, here's my question: what is/was so bad about pppd + natd? > > > > Generating >10% of the total support load for FreeBSD on IRC is so bad > > about it. And I can't give you a better answer than that, because I > > haven't supported it in 3.5 years and do not remember what problems > > people were having - and if it had been a single problem or two (as > > you imply with your questions), I'd have SOLVED THOSE PROBLEMS rather > > than going for the blanket. > > > So you can't recall a single specific problem, other than saying they > were. There were no problems *per se* - there is nothing that inherently doesn't work with the configuration. I could say some people had problems configuring divert sockets. I could say some people had problems getting ipfw to work at all. I could say some people had problems with not having supplied -dynamic to natd. I could say some people didn't discover the -n option to natd. I could say some people had problems writing the script for pppd. I could say some people had problems with their kernel not containing the ppp device. And I could wring my brain to find more examples. However, I didn't see this as much of a point, because it does NOT add to the overall point: There was a bunch of small problems that in total resulted in the this configuration leading to a bunch of support. > Okay, then how about querying our current FreeBSD users about > it? It's that simple: > > Dear users of pppd(8) + natd(8), if there are any. Do you have/had > any problems using this combination? I'd appreciate both successful > and unfortunate reports, to improve documentation. I don't believe you'll get any relevant responses to that. Besides, I'm not interested. I know the problem is there, as I've seen it. You don't believe me when I tell you that it is there - that's your choice. This is not an issue I care enough about to spent more energy on. And I'm not active enough that I feel I have any right to any form of veto. Eivind. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pppd + natd (was: Re: some bugs in natd.8)
> > And I'm not active enough that I feel I have any right to any form of veto. > > > Thanks. I'm not against documenting "something", if I understand > what this "something" should be. That people absolutely should use ppp -nat instead of pppd+natd, and that this goes even if people ALREADY has a working pppd configuration. Or at least this was my experience when I added this, based on what lead to how much support (which I roughtly equate with problems for the users.) And that this should be documented in the natd manpage, because *that is where the people affected will be looking when they are affected*. > If people want pppd(8) over ppp(8) or mpd(8) for some reason, the only > options to NAT they have are ipnat(8) and natd(8). You sounded like > natd(8) should not be used on anything except NICs, this I strongly > disagree to. I certainly do not for recommending ppp(8) over pppd(8), > or for recommending "ppp -nat" over "ppp + natd", but the former > does not belong to the natd(8) manpage, and the latter is documented > there. I do not understand what you are attempting to say here at all. Ref mpd: I might still have patches to support using libalias with this directly somewhere; I remember submitting them back in 1997 or early 1998. Whistle did not want to integrate them in their mainline, though, as they were using a different NAT library internally. Eivind. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
INVARIANTS and -current
(Based on suggestion from Robert Watson.) I want to enable INVARIANTS by default in -current. This result in some slowdown, but it also makes it more likely that we'll find bugs quickly. People that want to run -current should know enough to disable it if it is in the way, anyway. Well-reasoned objections welcome. Eivind. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: INVARIANTS and -current
On Tue, Oct 31, 2000 at 10:06:14PM -0700, [EMAIL PROTECTED] wrote: > Could someone give a quick explanation what INVARIANTS does? It adds more internal consistency checks to the kernel. This make bugs show up more promptly and in a more predictable fashion, which again makes it easier to fix the bugs. (It also makes the bugs more likely to result in a crash and less likely to result in data corruption, which IMO is good.) Eivind. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
