Re: Keeping User Database loaded in Mem
* :: Patrick Tracanelli :: [EMAIL PROTECTED] [010803 10:51] wrote: Hello you all; I want to know if there is a working way to keep FreeBSD's user database loaded in memory. The reason's for that is very clear, if i keep my spwd.db loaded the access to it won't be a disk access, so this will speedup any forms of authentication... The reason is that i want to avoid SQL databases in some cases where the system database works better to me. I have calculated that a database amount of 3000 (+/-) users would need about 7.6MB of memory, what sounds very good to me... If there isn't a way to it, yet, that is something i would love to see when -CURRENT becomes -RELEASE... it's an idea :) The filesystem cache should keep the database in memory as long as there is no pressure on the cache, otherwise it may evict the file. If you _really_ want to keep it in memory what I would suggest is writing a daemon that monitors the size of the file and keeps it both mmap(2)'s and mlocked(2), this would be trivial to do and would force the system to keep the file in memory. -- -Alfred Perlstein [[EMAIL PROTECTED]] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
No Subject
Peter Sides
Re: quick query
Paul [EMAIL PROTECTED] wrote: sorry to bug this list with this question. I'd like to test the newer ray(4) driver that's in -CURRENT. What snapshot should I install? Is there anything else I should know before installing -CURRENT? (besides what the cutting edge section of the handbook says) I just installed the latest snapshot available from current.freebsd.org (20010618, I think) and then went from there to the latest sources using CVSup. That was on Thursday evening. Buildworld etc. went without a problem, and the box (a dual Celeron-466) is running happily since then, with SMP enabled, Soft-updates and what-have-you. Of course you should read src/UPDATING and have an eye on this mailing list and on the commits. Regards Oliver PS: My reason to try out -current was the umass driver. I was hoping to get a USB-IDE box running, but it does not look like it's willing to work with FreeBSD. :( -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. All that we see or seem is just a dream within a dream (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ntpd 4.1
On Fri, 3 Aug 2001, Sheldon Hearn wrote: On Fri, 03 Aug 2001 10:18:49 +0200, Sheldon Hearn wrote: So let me guess. Not only does Mills think that the web is the only sensible distribution medium for documentation, he also thinks that English is the only sensible language for it? Ha, you think that's bad. Mills doesn't want to be bothered to change his ways to use any sort of revision control. That's how set in his ways he is. Almost as bad as Linus. -gordon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ntpd 4.1
On Sat, Aug 04, 2001 at 02:03:10PM -0700, Gordon Tetlow wrote: Ha, you think that's bad. Mills doesn't want to be bothered to change his ways to use any sort of revision control. That's how set in his ways he is. Almost as bad as Linus. :pserver:[EMAIL PROTECTED]:/cvs/ntp You can checkout modules 'ntp' or 'ntpfaq'. Been there for a rather long time. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ntpd 4.1
On Sat, 4 Aug 2001, Mixtim wrote: On Sat, Aug 04, 2001 at 02:03:10PM -0700, Gordon Tetlow wrote: Ha, you think that's bad. Mills doesn't want to be bothered to change his ways to use any sort of revision control. That's how set in his ways he is. Almost as bad as Linus. :pserver:[EMAIL PROTECTED]:/cvs/ntp You can checkout modules 'ntp' or 'ntpfaq'. Been there for a rather long time. Actually, I was talking with the guy that manages the cvs repo for it. From what I gather (and the cvs repo seems to back up) is that Mills has never actually committed a thing. Harlan Stenn does most of the CVS work. -gordon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ntpd 4.1
According to Gordon Tetlow: From what I gather (and the cvs repo seems to back up) is that Mills has never actually committed a thing. Harlan Stenn does most of the CVS work. That's correct. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Should developers run current ? (was: XDM and X)
I've cc'd freebsd-current here. This is a followup to a small thread on the UK user group list about the stability of -stable. Joe Karthauser [EMAIL PROTECTED] wrote: On Sat, Aug 04, 2001 at 02:42:44PM +0100, Nik Clayton wrote: =20 This hasn't suddenly changed in FreeBSD -- the -current/-stable branches have worked like this since at least the 2.x days. It's always been the case that if you're using FreeBSD in a production environment you should deploy any new version on to test machines first, and make sure that it works in your environment. =20 I agree. Over the years I've updated many production servers to -stable, and of course periodically things break, I remember having major difficulties when r caused regular panics :) On the otherhand the majority of changes to -stable are for subsystems and rarely affect the stability of the entire machine. For my uses that was sufficient. Something has changed. IMHO the developer base has been segregated in the last year, mainly due to the the part-real, part-perceived instability of -current. There now seem to be two categories of developer: o The developer that's too dumb/stupid/smart/proud/lazy to run -stable and will keep fighting any problems that turn up in -current. o The developer that's probably been hit by one of the nastier -current bugs in the past year and has decided (on quite practical grounds) that it's better to develop under -stable. I believe this to be a bad thing. Back in the old days -stable was reserved for bug fixes and some features/enhancements. ABI and API changes weren't allowed. When someone made a mistake, they got the same clout across the back of the head that they do now, but things didn't break that often because relatively less was MFC'd. Now, because people are actively developing on -stable, they really need to push their work back into -stable so that they don't have to manage local source trees, trees that become more and more fragile as time passes. Because of this, -stable is now pretty similar to the -current we had a couple of years ago something that breaks a bit now and again, but not to a major degree as things should really be shaken out to some extent before they're committed there. -stable is no longer a branch that you can follow with a production system -- it's too risky. To this end, the RELEASE branches have been created. The release branches kind of address the problem because what's merged into them is kept to a minimum and is controlled by a few individuals that will not bend it's charter. There are downfalls to this system though - namely that each minor release upgrade contains huge numbers of feature additions/enhancements, making it difficult for people to regression-test production systems. Personally, I believe that the developers that are now developing under -stable should simply be lured back onto -current. Doing this may be enough to make -stable stable again -- if developers have no big incentive or requirement to have their code in -stable, but just have the overheads of having to merge it and read the -stable list, it may tip the balance back towards how things worked before. I appreciate that there are a huge number of issues -- things such as -current carrying so many enhancements that a major release upgrade becomes an enormous task. I believe there should be a balance somewhere, and to get closer to that balance, we need to attract our developers back to -current. Joe -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Should developers run current ? (was: XDM and X)
On Sun, Aug 05, 2001 at 01:26:34AM +0100, Brian Somers wrote: Back in the old days -stable was reserved for bug fixes and some features/enhancements. ABI and API changes weren't allowed. When someone made a mistake, they got the same clout across the back of the head that they do now, but things didn't break that often because relatively less was MFC'd. This discussion comes up periodically (usually, once per code freeze ;-) I don't think the high rate of MFCs mostly occurs because developers develop on -stable, it's because the branch can't be allowed to diverge too much from -current or porting of bugfixes becomes difficult (especially kernel bugfixes, but also other actively-developed or heavily modified systems). Many people feel seem to that the fact that this divergence was allowed to creep in between the 3.x/4.0-CURRENT branches contributed heavily to the continued poor stability of the 3.x branch towards the second half of its release cycle when it should be expected instead to mature and stabilize. If the developers all run -current, and -current is incompatible with -stable, then -stable also suffers in quality. There's a balance which needs to be struck. I run -stable on several systems and regularly upgrade. I haven't encountered sudden instability, incompatibility or sudden onset of problems. Personally, I don't think things are so bad in -stable land. Kris PGP signature
Re: What's touching my executables?
I wrote: An increasing number of executables on that box are sporting ever newer mtimes. This appears to have been going on ever since the Jul 25 update. There is no clear pattern which executables are touched. md5 comparisons with previous backup levels (using a Jul 13 copy of md5) suggest that the executables have not been changed. I have updated the box (HEAD from Friday, alpha). The phenomenon still persists. I haven't observed any mtime changes on non-executable files. I'm running a small program that uses a kqueue(2) EVFILT_VNODE/NOTE_ATTRIB filter to watch for changes to /bin/*. During the last few hours some files there have changed their mtime without a kernel event being triggered. (An explicit touch(1) does trigger an event.) -- Christian naddy Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ntpd 4.1
On Thu, Aug 02, 2001 at 12:25:13PM +0200, Ollivier Robert wrote: Now that ntpd 4.1.0 has been released (finally!), I'll upgrade current very soon. The question I have is the following: authentication was done with md5 code builtin and I disabled DES support (not supported anymore). Now, with 4.1, it can be linked to openssl but it is still an optional component. I'm a bit reluctant to force openssl for just ntpd. Any ideas / comments ? What we do for a number of other system components that can be built with/without openssl/crypto support is to select that based on NO_OPENSSL (and some other -- semi-redundant -- checks), and make sure it's built twice in make release. Look at release/Makefile and the ppp and tcpdump code to see how it's done. Kris PGP signature
RE: snapshot installation woes
On 04-Aug-01 Gordon Tetlow wrote: I decided I was going to brave 5.0-CURRENT and give the snapshots available on current.jp.freebsd.org a try. I found a couple issues with installation disks (FWIW, I tried it on the lastest snapshot avail on current.freebsd.org. I got the same results). Anyway, I go through the standard kern/mfsroot floppy deal and when it boots the kernel, everything seems to be going fine until I get the following kernel panic: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xffab That's a NULL pointer deref. fault code= supervisor write, page not present instruction pointer = 0x8:0xc0a75ac0 Hmmm... Can you look in the bin dist for the kernel.debug and do a 'gdb -k' on it to look up this address to see what line it is dying on? No idea on the ahc0 error. :( -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: quick informal survey: OpenSSH broken?
On Wed, Aug 01, 2001 at 08:21:14PM +0200, Jens Schweikhardt wrote: On Tue, Jul 31, 2001 at 03:13:58PM -0700, David O'Brien wrote: # On Tue, Jul 31, 2001 at 01:39:14PM -0400, Robert Watson wrote: # what was going on, and given that scp doesn't support -1, was a bit of a # pain. # # Brian, what about adding -1 to SCP? I'm late in this thread, so I don't know what has been discussed before, but if this means to use protocol version one, scp does this already with scp -o Protocol=1 ... Yes, but that is a whole lot more to have to type than `scp -1', and since we want to encorage poeple to use ssh/scp and it is typed so often, it would be nice (and oroginal since ssh has it) to add -1 to scp. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
snapshot installation woes
I decided I was going to brave 5.0-CURRENT and give the snapshots available on current.jp.freebsd.org a try. I found a couple issues with installation disks (FWIW, I tried it on the lastest snapshot avail on current.freebsd.org. I got the same results). Anyway, I go through the standard kern/mfsroot floppy deal and when it boots the kernel, everything seems to be going fine until I get the following kernel panic: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xffab fault code = supervisor write, page not present instruction pointer = 0x8:0xc0a75ac0 stack pointer = 0x10:0xc6978f68 frame pointer = 0x10:0xc6978f80 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupts enabled, resume, IOPL = 0 current process = 26 (irq10:sn0) trap number = 12 panic: page fault syncing disks... done Uptime: 2s FWIW, it's 5.0-20010804-JPSNAP #0 available off of current.jp.freebsd.org. I noticed it said it was in sn0. So being industrious, I interrupted the autoboot and did: ok set hint.sn.0.disabled=1 Sure enough, that fixed the kernel panic, but here's the next odd piece, my hard drive wasn't showing up! I have a rather standard Adaptec AHA-2940 dmesg reports that ahc0 is there. The lines from the dmesg are (hand typed): ahc0: Adaptec 2940 Ultra SCSI adapter port 0x5000-0x50ff mem 0x5000-0x5fff irq 15 at device 15.0 on pci0 device_probe_and_attach: ahc0 attach returned 12 errno.h says ENOMEM is 12, so it seems that something in the ahc driver is unable to allocate memory. Dunno where or why, but something is fouling it up. By contrast 4.3-RELEASE doesn't have any issues (I'll try a recent snapshot if that would help). Sorry I can't help out any more, but the debugging tools in the installation disks seem to lacking (understandably). Any help? -gordon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Userbase of -current
On Thu, Jul 19, 2001 at 10:30:42AM -0500, some SMTP stream spewed forth: On Wed, Jul 18, 2001 at 09:34:41PM -0400, a little birdie told me that Garance A Drosihn remarked At 11:18 PM -0700 7/17/01, Peter Wemm wrote: If I had to guess, I'd put the total [genuine] -current userbase at between 20 and 50 people. And many of those intentionally lag by a few weeks to a month or two. I have a strong feeling that the -CURRENT userbase is quite a bit larger than that, but I have nothing conclusive. At the kernel-confab at usenix, I heard some people talking about how current wasn't really as bad as people assume it is. I must admit I wonder how much current is actively used. I know I try to build a new up-to-date current every two or three weeks, but I don't do much more on it than test a few changes. I am certainly not stress-testing it. Almost all of my real day-to-day work is done on machines which are tracking -stable. FWIW, without extraordinary reason, I don't run 'production' machines on -CURRENT (I think the last time I did so was when I ran a news server on 3.0-CURRENT). However, my workstation runs -CURRENT, and my dialup router does as well (mainly to make it easier to update), my laptop... come to think of it, almost all my of personal machines run -CURRENT, except for one that runs 2.1-STABLE (386SX. 4 MB RAM. 80 meg disk. Last benchmark: 13 days for a buildworld. Don't think I'll update it any time soon). I'll second this. I do all of my daily work on -CURRENT workstations, and I have had no siginificant problems since I started nearly two years ago. Of course, there is always the slim chance of some rogue (ah hem, un-thoroughly-tested) commit destroying something, but I have faith in the developer community. All my personal boxen (three, at the moment) run -CURRENT. I don't know if I would call my general use stress testing, but touch a large portion of the functionality on a daily (sometimes the days merge...) basis. -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Daniel M. Kurry -- What, no one sings along with Ricky Martin anymore? My kid sister does (but then, she prefers pico to vi ...) -- Suresh Ramasubramanian, alt.sysadmin.recovery To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: md/mdmfs bugs
Kris Kennaway [EMAIL PROTECTED] writes: 1) For some reason, my mdmfs line in /etc/fstab always does a chmod 777 /tmp at mount-time /dev/md0/tmpmfs rw,-s=65536 0 0 As previously threatened, I implemented bug-to-bug compatibility with mount_mfs(). The patch is attached below. Please try it and see if it fixes this problem. Here's an excerpt from the manual page that roughly describes what I did: COMPATIBILITY mdmfs, while designed to be fully compatible with mount_mfs(8), can be useful by itself. Since mount_mfs(8) has some silly defaults, a ``full compatibility'' mode is provided for the case where bug-to-bug compati- bility is desired. Full compatibility is enabled with the -C flag, or by starting mdmfs with mount_ at the beginning of its name (as returned by getprogname(3)). In this mode, only the options which would be accepted by mount_mfs(8) are valid. Furthermore, the following behavior, as done by mount_mfs(8), is duplicated: o The file mode of mount-point is set to 01777 as if -p 1777 was given on the command line. If you have a link from /sbin/mount_mfs to /sbin/mdmfs, you don't need to worry about all that stuff. Just apply the patch below, build it, copy it to /sbin, and umount/mount /tmp; it should DTRT. Please let me know how it works out. Thanks. Index: mdmfs.8 === RCS file: /ref/cvsf/src/sbin/mdmfs/mdmfs.8,v retrieving revision 1.6 diff -u -r1.6 mdmfs.8 --- mdmfs.8 2001/07/30 09:13:21 1.6 +++ mdmfs.8 2001/08/05 00:17:02 @@ -25,7 +25,7 @@ .\ .\ $FreeBSD: src/sbin/mdmfs/mdmfs.8,v 1.6 2001/07/30 09:13:21 dd Exp $ .\ -.Dd May 26, 2001 +.Dd August 5, 2001 .Dt MDMFS 8 .Os .Sh NAME @@ -35,7 +35,7 @@ driver .Sh SYNOPSIS .Nm -.Op Fl DLMNSX +.Op Fl DLMNSUX .Op Fl a Ar maxcontig .Op Fl b Ar block-size .Op Fl c Ar cylinders @@ -53,6 +53,24 @@ .Op Fl w Ar user : Ns Ar group .Ar md-device .Ar mount-point +.Nm +.Fl C +.Op Fl NU +.Op Fl a Ar maxcontig +.Op Fl b Ar block-size +.Op Fl c Ar cylinders +.Op Fl d Ar rotdelay +.Op Fl e Ar maxbpg +.Op Fl F Ar file +.Op Fl f Ar frag-size +.Op Fl i Ar bytes +.Op Fl m Ar percent-free +.Op Fl n Ar rotational-positions +.Op Fl O Ar optimization +.Op Fl o Ar mount-options +.Op Fl s Ar size +.Ar md-device +.Ar mount-point .Sh DESCRIPTION The .Nm @@ -110,6 +128,13 @@ option). .It Fl b Ar block-size The block size of the filesystem, in bytes. +.It Fl C +Enable full compatibility mode with +.Xr mount_mfs 8 . +See the +.\ XXX link to another section? +.Em COMPATIBILITY +section for more information. .It Fl c Ar cylinders The number of cylinders per cylinder group in the filesystem. .It Fl D @@ -192,6 +217,13 @@ .Xr malloc 9 backed disks .Pq Dv MD_MALLOC . +.It Fl U +Enable soft-updates on the filesystem. +This is the default, even in compatibility mode, and is accepted only +for compatibility. +It is only really useful to negate the +.Fl S +flag, should such a need occur. .It Fl w Ar user : Ns Ar group Set the owner and group to .Ar user @@ -257,8 +289,46 @@ .Cm async : .Pp .Dl mdmfs -M -S -o async -s 16m md1 /tmp +.Sh COMPATIBILITY +.Nm , +while designed to be fully compatible with +.Xr mount_mfs 8 , +can be useful by itself. +Since +.Xr mount_mfs 8 +has some silly defaults, a +.Dq full compatibility +mode is provided for the case where bug-to-bug compatibility is desired. +.Pp +Full compatibility is enabled with the +.Fl C +flag, +or by starting +.Nm +with +.Li mount_ +at the beginning of its name +(as returned by +.Xr getprogname 3 ) . +In this mode, only the options which would be accepted by +.Xr mount_mfs 8 +are valid. +Furthermore, the following behavior, as done by +.Xr mount_mfs 8 , +is duplicated: +.Bl -bullet -offset indent -compat +.It +The file mode of +.Ar mount-point +is set to +.Li 01777 +as if +.Fl p Ar 1777 +was given on the command line. +.El .Sh SEE ALSO .Xr md 4 , +.Xr fstab 5 , .Xr disklabel 8 , .Xr mdconfig 8 , .Xr mount 8 , Index: mdmfs.c === RCS file: /ref/cvsf/src/sbin/mdmfs/mdmfs.c,v retrieving revision 1.5 diff -u -r1.5 mdmfs.c --- mdmfs.c 2001/07/30 09:11:17 1.5 +++ mdmfs.c 2001/08/05 00:18:38 @@ -65,6 +65,7 @@ bool mi_have_mode; }; +static bool compat;/* Full compatibility with mount_mfs? */ static bool debug; /* Emit debugging information? */ static bool loudsubs; /* Suppress output from helper programs? */ static bool norun; /* Actually run the helper programs? */ @@ -115,8 +116,12 @@ newfs_arg = strdup(); mount_arg = strdup(); + /* If we were started as mount_*, imply -C. */ + if (strncmp(getprogname(), mount_, 6) == 0) + compat = true; + while ((ch = getopt(ac, av, -
