Re: Disk quotas out of sync
On Mon, Aug 18, 2008 at 07:16:53PM -0400, Simon wrote: > Hello All, > > I sent this to freebsd-questions but it went unanswered, hoping for better > luck here. The issue I'm trying to resolve is this: > > Ever since I went from 6.x to 7.0-R I have started experiencing disk quotas > getting out of sync with the actual amount used. For example, a user with > 100GB used disk space suddenly shows usage of only 80GB as if the data > is gone, but it isn't. This forces me to run quotacheck -av often. Was > something changed regarding quotas in 7.0-R? Nobody else noticed this issue? > I have this issue across multiple, different hardware, servers running 7.0-R > > Thank you for any insight and help in advance! > > -Simon What do your quota options look like in rc.conf? And what does the fstab look like for the file system in question? -- Mike Pritchard mpp @ FreeBSD.org "If tyranny and oppression come to this land, it will be in the guise of fighting a foreign enemy." - James Madison (1787) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: quotactl returns double values
On Sun, Feb 10, 2008 at 01:04:24PM +0900, Tod McQuillin wrote: > On Sat, 9 Feb 2008, Ivan Georgiev wrote: > > >I was just playing, trying to see how quotactl works, > >but in all my tries the values returned are doubled, > > > >the values stored in my_st->dqb_bhardlimit and my_st->dqb_curblocks > >are the real values times two, the hard limit on the user is 102400K, > >but my_st->dqb_bhardlimit holds 204800K. > > I hope you are remembering that the limits are measured in blocks -- a block > is > 512 bytes. > > Thus a limit of 102400K is 204800 blocks, since each 1K holds 2 blocks. You can also use "quota -r" to dump out the raw quota data. Simple answer is, internally the quota system maintains its block counts by counting the # of blocks that would be returned by stat(2) in the st_blocks field, which is the # of 512-byte blocks used by the file. Externally, (e.g. what it displays, takes as input) is 1024-byte blocks counts. -- Mike Pritchard mpp @ FreeBSD.org "If tyranny and oppression come to this land, it will be in the guise of fighting a foreign enemy." - James Madison (1787) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Request for feedback on 2 new quota command options
I'd like to add 2 new options to the quota command, and would like to see if there are any comments before I commit them. The new options are: -f filesystem Only display information for the specified file system. -r Display the information as it appears in the quota structure, without any block translation and display the grace time values in more detail. E.g. instead of saying 6days for the time left, the actual time_t data and the time in ctime(3) format will be displayed. Both options have been useful in helping debug quota problems. Sample output from "quota -r -f /sandbox -u quotatest": Raw user quota information for id 1016 on /sandbox block hard limit: 1800 block soft limit: 1200 current block count: 6752 i-node hard limit:11 i-node soft limit:6 current i-node count: 5 block grace time: 1171080257 Fri Feb 9 22:04:17 2007 i-node grace time:0 The patch is available at: http://people.freebsd.org/~mpp/quota.patch -Mike -- Mike Pritchard mpp @ mppsystems.com or mpp @ FreeBSD.org "If tyranny and oppression come to this land, it will be in the guise of fighting a foreign enemy." - James Madison (1787) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sitting on hands (no longer Re: FreeBSD vs Linux, Solaris, and NT)
Just a comment on this... I used to work for a pretty big Unix OS vendor in the operating systems development group. 90% of the bug fixes I applied were never found by the QA group (otherwise they would have been fixed long before I ever worked there :-). Where they really found problems were cross-platform problems. E.g. I committed a change, tested it on platform X & Y and it worked just fine. It failed to build on legacy platform Z. Building and testing on platform Z was near impossible, so as a developer, unless you were actually fixing a problem for platform Z, you never did it. After being bit a couple of times, I automated a script that did the cross-build, and never got bit again, but most people didn't do that. Heck, a major part of the QA group was dedicated to making sure the documentation was correct (not a bad thing, but it didn't help the actualy state of the software). Our -current works pretty much like the QA we had at this company. Most machines ran what we call -stable. All development machines (and there were a lot) ran -current, and a few ran a couple of releases back, just in case we had to fix something in that release. Knowing how many people actually run -current, I would say we have better testing than the OS company I worked for. Even though we don't have a real "QA" dept. -Mike On Thu, Dec 21, 2000 at 09:48:44AM -0800, SteveB wrote: > Here's the thing about open software that still concerns me. My > background is with the major software development tools companies, so > that is my point of reference. It is great that code is available and > fixes are made and pushed out, but who is doing real testing of these > fixes. Sure the obvious problem is fixed, but what other problems has > it uncovered, what side effect has it created, and how about > compatibility with other software or drivers in this case. > > With commercial software (well at least the places I worked) nothing > could go out the door without a complete QA cycle performed on it. > Even the smallest of bug fixes couldn't be released without a QA > cycle. A full QA cycle was time consuming and expensive, so fixes sat > until there was a stack of them to QA'd as a group or they had to wait > until next upgrade. That way we knew state of the product. Yes, the > state of the product would include known bugs. The key was a known bug > and a known documented bug was as valuable as a fix. Sure a bug is > bad, but if it is documented you don't waste trying to make something > work that is known to be broke. > > So who is testing these fixes in open source world? Just seeing if > the problem at hand is gone isn't real testing, even claiming > thousands of people are now using it isn't enough. There can still be > lurking potentially data destroying bugs lurking. In the open source > world is there a official QA process or group. Is there a FreeBSD > test suite that releases go through. QA is unglamorous work, but > needs to be done. > > Steve B. -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: COMPAT_43 and kernel compiles.
On Sun, Aug 13, 2000 at 06:19:37PM +1000, Darren Reed wrote: > > Darren Reed wrote: > > > > > > Is it meant to be possible to compile a kernel *without* COMPAT_43 ? > > > > > > Has anyone else tried this recently ? > > > > > > For me, it seems to break the compile in (at least) kern_sig.c I doing this for a while, and I think the last signal interface change broke not being able to compile a kernel without COMPAT_43. This was a while back, and someone was supposed to be working on it to fix it. I might be able to dig some more info up if anyone wants it. > > >From /sys/i386/conf/NOTES: > > > > # > > # Implement system calls compatible with 4.3BSD and older versions of > > # FreeBSD. You probably do NOT want to remove this as much current code > > # still relies on the 4.3 emulation. > > # > > options COMPAT_43 > > If it is to not be an option, then it should be deprecated as an option > and all of that removed. FWIW, I tested NetBSD-current without this > option and it compiles cleanly (not that I used it). Seems like someone > needs to make a decision one way or the other about COMPAT_43 and FreeBSD. It used to be possible to compile and run kernels with COMPAT_43 undefined. -Mike -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PC Keyboard Scancodes
Here are the codes for the Compaq "Easy Access Internet Keyboard". They also have a newer version with even more buttons, but I don't have access to one, so I can't supply the codes for it. If someone is going to do some work to get the Microsoft keyboard's extra keys to work, it shouldn't be hard to integrate these keys at the same time. play/pause-32 34 -32 -94 stop -32 36 -32 -92 prev. track -32 16 -32 -112 next track-32 25 -32 -103 sleep -32 95 -32 -33 mute -32 32 -32 -96 vol - -32 46 -32 -82 vol + -32 48 -32 -80 launch app-32 31 -32 -97 search-32 33 -32 -95 internet -32 35 -32 -93 secure e-commerce -32 50 -32 -78 e-mail-32 30 -32 -98 -Mike -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
xntpd & xcdplayer
I've noticed something peculiar over the past week or so with xntpd and I think xcdplayer (from ports). I am running xntpd to keep my clock right. I have an always on DSL connection, so I almost never see any output from xntpd. However, I've noticed that the past few times I've started playing a CD with xcdplayer, I get the following out of xntpd: Oct 27 04:10:44 mpp xntpd[153]: Previous time adjustment didn't complete Which is somewhat odd, because the last message from xntpd about adjusting the time was over 13 hours ago (and it was a 0.129016 s adjustment). Right now I am running a -current kernel from 10/17. The CD drive in question is an ATAPI device. Vendor supplied generic CD drive and builtin IDE on the mother board, so I have no idea what exactly what hardware I have :-(. Usually on the first spin up of the CD after a long period of inactivity, the machine will "pause" (mouse won't move, etc...), so I'm thinking that this might be causing something in the clock code to suffer a small stutter and cause xntpd to print out its message. Normally I ignore whatever xntpd tells me, unless it reports a large time difference. But, tonight when I was checking my mail and decided to listen to a CD while doing so, I got the "Previous time adjustment..." message right away after starting to play the CD. And after thinking back, it seems to me that I see more of around the time when I'm playing CDs, so it seems like the two might be related. It isn't a big deal to me, but I thought I would ask about it. Now, if anyone wants to donate me a nice Adaptec SCSI controller and SCSI CD drive, and maybe a hard drive:-) -Mike -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to prevent motd including os info
> "Rodney W. Grimes" wrote: > > > It dawned on me what can be done. Look, we get all the kernel printf's > > from the dmesg output saved in a buffer and pull that out later with > > syslog, looks like we could just slip a pipe fitting into /dev/console > > that copies all it's output into the mesgbuf as well, until we smack it > > wth the ballpean and tell it to stop doing that (Either getty lanching the > > login: on ttyv0 could cause this, or something at the end of /etc/rc). > > > > What do you think of that idea? > > I think that's a fine idea, and it's a lot cleaner than mine for a number > of reasons. Completely beyond me to code, but very nice from the design > standpoint. Most of the time I could care less what /etc/rc spits out. However, in the past, I have had to go add sleep(###) calls in various spots in rc to that I could actually read some of the error output to figure out why something was failing. I wouldn't mind having all of the /etc/rc output sent to the message buffer (and /dev/console) until a getty is running on ttyv0. Or at least make it a boot option. If you are having problems, boot the kernel with "boot -l" in the boot loader. Now, adding an option doesn't help in the case of fsck suddenly generating a million lines of output during boot, since that might not be expected, but it does help some cases. And scrollback buffers and message buffers only help if you have enough memory to hold all of that information. Right now I have 3 FreeBSD machine. 1 has 192MB of RAM. I have the message buffer set to some very large value (because of some boot problem I bumped it up a lot), so I at least see all of the kernel messages that were generating during a boot. This helped me debug a couple of problems. The other two machines only have 16MB, so they still run with a standard message buffer (geez, I remember when 16MB was *A LOT*). Perhaps we need a "boot message buffer" (just eat up free memory minus some protected space that is reserved for letting /etc/rc run without swapping). Keep sending data to that buffer during the boot process, and just before going multi-user, dump it off to disk and free it. On a 16MB machine, that shouldn't be a problem. For those people still running FreeBSD machines on 4MB, that is another story, but even in those cases, I would bet you could still be able to record and store at least some of the /etc/rc output. Its been a few years since I've seen fsck generate a couple of megabytes of output, so I know it is possible, but I think this idea could work, and solve most peoples problem of fsck generating MANY pages of output that just scroll by. -Mike -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to prevent motd including os info
> "Rodney W. Grimes" wrote: > > > It dawned on me what can be done. Look, we get all the kernel printf's > > from the dmesg output saved in a buffer and pull that out later with > > syslog, looks like we could just slip a pipe fitting into /dev/console > > that copies all it's output into the mesgbuf as well, until we smack it > > wth the ballpean and tell it to stop doing that (Either getty lanching the > > login: on ttyv0 could cause this, or something at the end of /etc/rc). > > > > What do you think of that idea? > > I think that's a fine idea, and it's a lot cleaner than mine for a > number > of reasons. Completely beyond me to code, but very nice from the design > standpoint. Most of the time I could care less what /etc/rc spits out. However, in the past, I have had to go add sleep(###) calls in various spots in rc to that I could actually read some of the error output to figure out why something was failing. I wouldn't mind having all of the /etc/rc output sent to the message buffer (and /dev/console) until a getty is running on ttyv0. Or at least make it a boot option. If you are having problems, boot the kernel with "boot -l" in the boot loader. Now, adding an option doesn't help in the case of fsck suddenly generating a million lines of output during boot, since that might not be expected, but it does help some cases. And scrollback buffers and message buffers only help if you have enough memory to hold all of that information. Right now I have 3 FreeBSD machine. 1 has 192MB of RAM. I have the message buffer set to some very large value (because of some boot problem I bumped it up a lot), so I at least see all of the kernel messages that were generating during a boot. This helped me debug a couple of problems. The other two machines only have 16MB, so they still run with a standard message buffer (geez, I remember when 16MB was *A LOT*). Perhaps we need a "boot message buffer" (just eat up free memory minus some protected space that is reserved for letting /etc/rc run without swapping). Keep sending data to that buffer during the boot process, and just before going multi-user, dump it off to disk and free it. On a 16MB machine, that shouldn't be a problem. For those people still running FreeBSD machines on 4MB, that is another story, but even in those cases, I would bet you could still be able to record and store at least some of the /etc/rc output. Its been a few years since I've seen fsck generate a couple of megabytes of output, so I know it is possible, but I think this idea could work, and solve most peoples problem of fsck generating MANY pages of output that just scroll by. -Mike -- Mike Pritchard m...@freebsd.org or m...@mpp.pro-ns.net To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: CS Project
> On Wed, Sep 08, 1999, Gustavo V G C Rios wrote: > > Dear gentleman, > > > One clear example: > > No user(but only that ones previous allowed to) should be able to see > > other users process. This facility have to be done at kernel level, > > (that's what i think). > >Define "see". Access the memory? See that it is running? > View the argv list? I don't see how this would affect privacy. I used to work somewhere where we didn't wany any of the users to know anything about any other groups of users processes. We did this by restricting ps to only show other procs that had the same primary group as the person executing ps. Root and group wheel (or some equivalent) could always see all running procs. You could always go hunting through the file systems, but their own directory permissions were their problem, not ours. This was a computing center site with several Crays, where customer names were kept private, and we had companies that were in competition with each other using our machines. The competition didn't want each other even knowing what applications they were running, because that might give them some insight into what they were doing (keyword here: paranoid). We might have also hacked w/who/finger/last to never print the host names/addresses so no one could nslookup the addresses and really figure out where the customers were logging in from. This was to stop them from finding out the competition was also one of our customers. So I can see situations where this might be useful, I'm not sure that these types of customers are really going to ever be sharing a FreeBSD machine, but you never know. -Mike -- Mike Pritchard m...@freebsd.org or m...@mpp.pro-ns.net To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: CS Project
> On Wed, Sep 08, 1999, Gustavo V G C Rios wrote: > > Dear gentleman, > > > One clear example: > > No user(but only that ones previous allowed to) should be able to see > > other users process. This facility have to be done at kernel level, > > (that's what i think). > >Define "see". Access the memory? See that it is running? > View the argv list? I don't see how this would affect privacy. I used to work somewhere where we didn't wany any of the users to know anything about any other groups of users processes. We did this by restricting ps to only show other procs that had the same primary group as the person executing ps. Root and group wheel (or some equivalent) could always see all running procs. You could always go hunting through the file systems, but their own directory permissions were their problem, not ours. This was a computing center site with several Crays, where customer names were kept private, and we had companies that were in competition with each other using our machines. The competition didn't want each other even knowing what applications they were running, because that might give them some insight into what they were doing (keyword here: paranoid). We might have also hacked w/who/finger/last to never print the host names/addresses so no one could nslookup the addresses and really figure out where the customers were logging in from. This was to stop them from finding out the competition was also one of our customers. So I can see situations where this might be useful, I'm not sure that these types of customers are really going to ever be sharing a FreeBSD machine, but you never know. -Mike -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Please review: rc file changes
> On Sat, Aug 28, 1999, Tim Vanderhoek wrote: > > A sentence ends > > .Ar here . > > But this new one has a single space preceeding it. > >Does adding a space after the `.' at the end of your line > help? Please, no trailing white space :-)! Seriously, I think that all of the current mdoc macros that allow puncuation characters to be specified screw this up and only add one space. Mdoc should be fixed to add two spaces in this case, and then if the man page author really does only want one space, they can do it with the existing Ns macro (no space). -Mike -- Mike Pritchard m...@freebsd.org or m...@mpp.pro-ns.net To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Please review: rc file changes
> On Sat, Aug 28, 1999, Tim Vanderhoek wrote: > > A sentence ends > > .Ar here . > > But this new one has a single space preceeding it. > >Does adding a space after the `.' at the end of your line > help? Please, no trailing white space :-)! Seriously, I think that all of the current mdoc macros that allow puncuation characters to be specified screw this up and only add one space. Mdoc should be fixed to add two spaces in this case, and then if the man page author really does only want one space, they can do it with the existing Ns macro (no space). -Mike -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Please review: rc file changes
> On Fri, Aug 27, 1999, Doug wrote: > > > > -# this file, but rather in /etc/defaults/rc.conf. Please check this > > > > file > > > > +# this file, but rather in /etc/defaults/rc.conf. Please check that > > > > file > > > Well, that was definitely the old typographical convention, but in > > the digital age it's fallen into disfavor. It was easier to delete the > > second space to make them all consistent, but I can go with double spaces > > if that's the consensus. > >I've never heard of that. I've always found that two spaces > after end-of-sentence punctuation makes things easier to read! > >(Don't think I don't appreciate this, I just love to nitpick. :) I vote for two spaces after the period before the start of a new sentence. Even in the digital age, I've always found that the two spaces make for better reading of text. I think that most of our formatting tools do this too (please don't flame me if I'm wrong :-). -Mike -- Mike Pritchard m...@freebsd.org or m...@mpp.pro-ns.net To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Please review: rc file changes
> On Fri, Aug 27, 1999, Doug wrote: > > > > -# this file, but rather in /etc/defaults/rc.conf. Please check this file > > > > +# this file, but rather in /etc/defaults/rc.conf. Please check that file > > > Well, that was definitely the old typographical convention, but in > > the digital age it's fallen into disfavor. It was easier to delete the > > second space to make them all consistent, but I can go with double spaces > > if that's the consensus. > >I've never heard of that. I've always found that two spaces > after end-of-sentence punctuation makes things easier to read! > >(Don't think I don't appreciate this, I just love to nitpick. :) I vote for two spaces after the period before the start of a new sentence. Even in the digital age, I've always found that the two spaces make for better reading of text. I think that most of our formatting tools do this too (please don't flame me if I'm wrong :-). -Mike -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Propose mdoc fix regarding ERRORS section
>Category: docs >Synopsis: src/lib/libc/sys/*.2 misc patch pack - first column in most ERROR lists is too narrow. Normalize their width. Right now we have a problem with our on-line man pages. Most were written when the length of errno's were only 6 - 8 characters long. Now we have errno's that can be up to 15 characters long. Many of our man pages have the following mdoc instruction (or something similar) to ensure that the field width for the errno is appropriate: .Bl -tag -width EBADFXXX As things have progressed, sometimes the errno names have become wider than the name specified in the .Bl macro. Man pages can also specify: .Bl -tag -width Er Which will reserve enough space for the errno name based on what width the Er macro specifies. Right now it doesn't allocate enough width to contain our largest errno's. I propose that we fix mdoc to allocate enough width when the second form is specified, and then change all of the man pages to use that format in the ERRORS section. Suggestions/comments/etc welcome. -Mike -- Mike Pritchard m...@freebsd.org or m...@mpp.pro-ns.net To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Propose mdoc fix regarding ERRORS section
>Category: docs >Synopsis: src/lib/libc/sys/*.2 misc patch pack - first column in most ERROR lists is too narrow. Normalize their width. Right now we have a problem with our on-line man pages. Most were written when the length of errno's were only 6 - 8 characters long. Now we have errno's that can be up to 15 characters long. Many of our man pages have the following mdoc instruction (or something similar) to ensure that the field width for the errno is appropriate: .Bl -tag -width EBADFXXX As things have progressed, sometimes the errno names have become wider than the name specified in the .Bl macro. Man pages can also specify: .Bl -tag -width Er Which will reserve enough space for the errno name based on what width the Er macro specifies. Right now it doesn't allocate enough width to contain our largest errno's. I propose that we fix mdoc to allocate enough width when the second form is specified, and then change all of the man pages to use that format in the ERRORS section. Suggestions/comments/etc welcome. -Mike -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: proposed change for /etc/periodic/* scripts
> Currently, the reports that are generated and emailed to root are > fine in what they do. however, a lot of the time there is actaully > nothing of interest in these reports if nothing has gone wrong > on the system etc. Basically I only want to know about the changes > that have happened. This would be useful in cutting down the size > of these emails esp. when you are receiving them from multiple > fbsd servers.. :P Make sure they always generate some output so that a message does get mailed. On more than once occasion I noticed that one of my boxes keeled over or the network broke when I didn't get my expected daily output from that machine. > example: > > * if there are no passwd/group diffs found, don't print anything > out (not even the header). Same for setuid etc. diffs. > > * For the 'df' status, only report filesystems that are over > a certain capacity (95% or only xxMb left etc..) You might want to make the df part an rc.conf (or maybe a new periodic.conf) knob. I have couple of machines that basically do nothing all week long and the disk space should always be pretty much constant. If I notice that the disk space usage changed a lot, then I should go check that machine out, because something went haywire. > and the same for all the other tests..basically if there's nothing > to report don't print anything (not even the header) otherwise > print the header and the results.. I've had a bad experience with this in the past. One of our adminstrators didn't like wading through all of the periodic output and changed the scripts to do what you want. Sometime down the line I figured out that he had broken something in the script early on and 90% of it never got executed, and since no output meant everything was fineyou get the point. Again, maybe an rc.conf knob that tells the periodic scripts to be "quiet". I've got a couple of machines here that I would might use that on, but not on my main servers. -Mike -- Mike Pritchard m...@freebsd.org or m...@mpp.pro-ns.net To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: proposed change for /etc/periodic/* scripts
> Currently, the reports that are generated and emailed to root are > fine in what they do. however, a lot of the time there is actaully > nothing of interest in these reports if nothing has gone wrong > on the system etc. Basically I only want to know about the changes > that have happened. This would be useful in cutting down the size > of these emails esp. when you are receiving them from multiple > fbsd servers.. :P Make sure they always generate some output so that a message does get mailed. On more than once occasion I noticed that one of my boxes keeled over or the network broke when I didn't get my expected daily output from that machine. > example: > > * if there are no passwd/group diffs found, don't print anything > out (not even the header). Same for setuid etc. diffs. > > * For the 'df' status, only report filesystems that are over > a certain capacity (95% or only xxMb left etc..) You might want to make the df part an rc.conf (or maybe a new periodic.conf) knob. I have couple of machines that basically do nothing all week long and the disk space should always be pretty much constant. If I notice that the disk space usage changed a lot, then I should go check that machine out, because something went haywire. > and the same for all the other tests..basically if there's nothing > to report don't print anything (not even the header) otherwise > print the header and the results.. I've had a bad experience with this in the past. One of our adminstrators didn't like wading through all of the periodic output and changed the scripts to do what you want. Sometime down the line I figured out that he had broken something in the script early on and 90% of it never got executed, and since no output meant everything was fineyou get the point. Again, maybe an rc.conf knob that tells the periodic scripts to be "quiet". I've got a couple of machines here that I would might use that on, but not on my main servers. -Mike -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port & BSD VFS Rewrite
> > On Sat, 14 Aug 1999, Leif Neland wrote: > > > > > [Regarding GPL] Can we please get this discussion out of -hackers, and into somewhere more apporipate like freebsd-advocacy. -- Mike Pritchard m...@freebsd.org or m...@mpp.pro-ns.net To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port & BSD VFS Rewrite
> > On Sat, 14 Aug 1999, Leif Neland wrote: > > > > > [Regarding GPL] Can we please get this discussion out of -hackers, and into somewhere more apporipate like freebsd-advocacy. -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs
> In article , > Bill Fumerola wrote: > > On Sat, 7 Aug 1999, Mike Pritchard wrote: > > > > > *default umask=002 > > > > SetAttrs CVSROOT/commitlogs/other.981201.gz > > > > That seems to be doing the trick for everything. Thanks. > > Note, if you would have just _run_ the program with a umask of 2 > then it would have worked too. It honors the umask setting unless > overridden in the supfile. Yes, but if I ever run cvsup by hand I wind up with cvsup going through my whole tree and resetting attributes because my default umask isn't 2. I once started up a cvsup by hand, sat down to eat/watch TV, came back and realized that cvsup had reset all of my file permissions. Putting it in the cvsup file help to make sure you don't screw yourself up by accident. -- Mike Pritchard m...@freebsd.org or m...@mpp.pro-ns.net To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs
> In article <[EMAIL PROTECTED]>, > Bill Fumerola <[EMAIL PROTECTED]> wrote: > > On Sat, 7 Aug 1999, Mike Pritchard wrote: > > > > > *default umask=002 > > > > SetAttrs CVSROOT/commitlogs/other.981201.gz > > > > That seems to be doing the trick for everything. Thanks. > > Note, if you would have just _run_ the program with a umask of 2 > then it would have worked too. It honors the umask setting unless > overridden in the supfile. Yes, but if I ever run cvsup by hand I wind up with cvsup going through my whole tree and resetting attributes because my default umask isn't 2. I once started up a cvsup by hand, sat down to eat/watch TV, came back and realized that cvsup had reset all of my file permissions. Putting it in the cvsup file help to make sure you don't screw yourself up by accident. -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs
> In message > Bill Fumerola writes: > : cvsup seems to set the wrong attributes after I've forced them to work > : that way. > > I see this when I cvsup as root too (although the file you quoted > should be r--r--r--. I can't get the modes on the directories to be > 775... Try adding this to your cvs-supfile: *default umask=002 -Mike -- Mike Pritchard m...@freebsd.org or m...@mpp.pro-ns.net To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs
> In message <[EMAIL PROTECTED]> Bill >Fumerola writes: > : cvsup seems to set the wrong attributes after I've forced them to work > : that way. > > I see this when I cvsup as root too (although the file you quoted > should be r--r--r--. I can't get the modes on the directories to be > 775... Try adding this to your cvs-supfile: *default umask=002 -Mike -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multiple versions of FreeBSD on one HDD
> At 8:01 PM +0200 8/3/99, Robert Nordier wrote: > > > > - If I select 3.2 at the PowerBoot menu, it comes up > > > with two messages about "invalid partition", [...] > > > It seems to want to boot 'da(0,a)/kernel', but if I > > > type in 'da(0,e)/kernel', then it boots up fine. > > > >The problem here is a missing `a' partition. Seems like your > >first partition on that slice is `e'. There's a one-line > >patch to boot2 to get this working, but the standard version > >only autoboots from the `a' partition. I have my main machine setup to boot 3 different operating systems all on one harddisk. My disk is paritioned into 4 fdisk partitions, as follows: 1: Win98 (ugh, but I need to have it to play games :-) (bootable) 2: extended dos partition (non-bootable) 3: FreeBSD 3.2-stable (bootable) 4: FreeBSD 4.0 -current (bootable) Here is my file system layout when running 4.0: /dev/wd0s4a on / (local, soft-updates, writes: sync 16 async 14249) /dev/wd0s3a on /root32 (local, writes: sync 2 async 44) /dev/wd0s3e on /root32/usr (local, writes: sync 2 async 7099) /dev/wd0s4f on /usr (local, soft-updates, writes: sync 2 async 8148) /dev/wd0s4h on /shared (local, soft-updates, writes: sync 1963 async 263656) /dev/wd0s3f on /root32/var (local, writes: sync 2 async 40) /dev/wd0s4g on /var (local, soft-updates, writes: sync 4604 async 69441) (along with a wd0s4b swap partition, which is shared between both FreeBSD versions) When I first tried this, I couldn't boot the 4.0 version because the 4.0 root device was named wd0s4e by my initial 3.2 sysinstall. I had to run disklabel and change the partition name to wd0s4a. After doing that, both versions would boot no problem. I just hit F3 for 3.2-stable, or F4 for 4.0-current. All of my boot blocks were orignally written out with 3.2-stable, but I've since re-written them with 4.0-current boot blocks. -Mike -- Mike Pritchard m...@freebsd.org or m...@mpp.pro-ns.net To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Multiple versions of FreeBSD on one HDD
> At 8:01 PM +0200 8/3/99, Robert Nordier wrote: > > > > - If I select 3.2 at the PowerBoot menu, it comes up > > > with two messages about "invalid partition", [...] > > > It seems to want to boot 'da(0,a)/kernel', but if I > > > type in 'da(0,e)/kernel', then it boots up fine. > > > >The problem here is a missing `a' partition. Seems like your > >first partition on that slice is `e'. There's a one-line > >patch to boot2 to get this working, but the standard version > >only autoboots from the `a' partition. I have my main machine setup to boot 3 different operating systems all on one harddisk. My disk is paritioned into 4 fdisk partitions, as follows: 1: Win98 (ugh, but I need to have it to play games :-) (bootable) 2: extended dos partition (non-bootable) 3: FreeBSD 3.2-stable (bootable) 4: FreeBSD 4.0 -current (bootable) Here is my file system layout when running 4.0: /dev/wd0s4a on / (local, soft-updates, writes: sync 16 async 14249) /dev/wd0s3a on /root32 (local, writes: sync 2 async 44) /dev/wd0s3e on /root32/usr (local, writes: sync 2 async 7099) /dev/wd0s4f on /usr (local, soft-updates, writes: sync 2 async 8148) /dev/wd0s4h on /shared (local, soft-updates, writes: sync 1963 async 263656) /dev/wd0s3f on /root32/var (local, writes: sync 2 async 40) /dev/wd0s4g on /var (local, soft-updates, writes: sync 4604 async 69441) (along with a wd0s4b swap partition, which is shared between both FreeBSD versions) When I first tried this, I couldn't boot the 4.0 version because the 4.0 root device was named wd0s4e by my initial 3.2 sysinstall. I had to run disklabel and change the partition name to wd0s4a. After doing that, both versions would boot no problem. I just hit F3 for 3.2-stable, or F4 for 4.0-current. All of my boot blocks were orignally written out with 3.2-stable, but I've since re-written them with 4.0-current boot blocks. -Mike -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> :> There may be some confusion here. I am advocating that we *allow* the > :> zeroing of counters at secure level 3. > : > :Which is what I am advocating against. > > Let me put it a different way: > > ipfw allows you to clear counters. It is a feature that already exists. > > However, it does not allow you to do it if you are sitting at secure > level 3. > > Why not? I can't think of any good reason why clearing the counters > should be disallowed when sitting at a higher secure level. The counters > are nothing more then statistics. Clearing statistics is not a security > threat. But it might be hiding a real security threat/attack or a real breakin. Say I've spent all night trying to hack into your machine and finally get in. If I can reset all of ipfw's counters back to zero, and this is something your security checking scripts are checking, you might not think that anyone has even been trying to break into your machine, much less made it into the machine. If I have some inside information, I could probably even get the counters back into the range where you might expect them to be at. Hopefully if this were to happen, you might see some other console/syslog messages or something else that catches your eye, but then again, maybe not. Just to help out people running at higher security levels, you could always implement something that lets you reset the values to some higher value that is easy to do computations from. E.g. ipfw --increment_counters=2 Which would bump all of the counters up to the value of "2", assuming they are all still less than that value. That way if you are trying to do some testing/debugging/counting after setting the counters, at least you have a nice round number to subtract from the current values. -- Mike Pritchard m...@freebsd.org or m...@mpp.pro-ns.net To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> :> There may be some confusion here. I am advocating that we *allow* the > :> zeroing of counters at secure level 3. > : > :Which is what I am advocating against. > > Let me put it a different way: > > ipfw allows you to clear counters. It is a feature that already exists. > > However, it does not allow you to do it if you are sitting at secure > level 3. > > Why not? I can't think of any good reason why clearing the counters > should be disallowed when sitting at a higher secure level. The counters > are nothing more then statistics. Clearing statistics is not a security > threat. But it might be hiding a real security threat/attack or a real breakin. Say I've spent all night trying to hack into your machine and finally get in. If I can reset all of ipfw's counters back to zero, and this is something your security checking scripts are checking, you might not think that anyone has even been trying to break into your machine, much less made it into the machine. If I have some inside information, I could probably even get the counters back into the range where you might expect them to be at. Hopefully if this were to happen, you might see some other console/syslog messages or something else that catches your eye, but then again, maybe not. Just to help out people running at higher security levels, you could always implement something that lets you reset the values to some higher value that is easy to do computations from. E.g. ipfw --increment_counters=2 Which would bump all of the counters up to the value of "2", assuming they are all still less than that value. That way if you are trying to do some testing/debugging/counting after setting the counters, at least you have a nice round number to subtract from the current values. -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)
> [trimming CC list] > > Dag-Erling Smorgrav wrote: > > > > Greg Lehey writes: > > > mdoc.samples(7). Now tell me that that's not intuitive. > > > > It would seem mdoc.samples(7) does not teach by example :) > > > > d...@des ~% man -t mdoc.samples | lpr -Plex > > Usage: .Rv -std sections 2 and 3 only > > This is a bug in man, actually. Section 7 is misc, and anything > *can* go there. It's perfectly possible to have something in need of > section 2/3 features that happens not to qualify as section 2 or 3. It isn't a bug in man. It is a problem with the mdoc macro package. Technically, mdoc.samples is using a *roff macro in a section that shouldn't be using that macro (the .Rv macro). I've known about this problem for quite some time, but just haven't been willing to commit the fix, since mdoc.samples(7) is the only man page that spits out this error. I do have a fixed version of the mdoc macro package that ignores this error for section 7 man pages. Since I've seen a few comments on this in the past few months, I suppose I'll break down and commit my changes. -- Mike Pritchard m...@freebsd.org or m...@mpp.pro-ns.net To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)
> [trimming CC list] > > Dag-Erling Smorgrav wrote: > > > > Greg Lehey <[EMAIL PROTECTED]> writes: > > > mdoc.samples(7). Now tell me that that's not intuitive. > > > > It would seem mdoc.samples(7) does not teach by example :) > > > > des@des ~% man -t mdoc.samples | lpr -Plex > > Usage: .Rv -std sections 2 and 3 only > > This is a bug in man, actually. Section 7 is misc, and anything > *can* go there. It's perfectly possible to have something in need of > section 2/3 features that happens not to qualify as section 2 or 3. It isn't a bug in man. It is a problem with the mdoc macro package. Technically, mdoc.samples is using a *roff macro in a section that shouldn't be using that macro (the .Rv macro). I've known about this problem for quite some time, but just haven't been willing to commit the fix, since mdoc.samples(7) is the only man page that spits out this error. I do have a fixed version of the mdoc macro package that ignores this error for section 7 man pages. Since I've seen a few comments on this in the past few months, I suppose I'll break down and commit my changes. -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)
> On Wednesday, 23 June 1999 at 9:12:12 +0300, Taavi Talvik wrote: > > On Tue, 22 Jun 1999, Jeroen Ruigrok/Asmodai wrote: > > If you write man pages first time, it is quite close to clack magic. > > It would be really nice if someone comfortant with troff/nroff etc. > > would make Handbook page describing how to get started with it. > > Maybe even templates or script generating page sceletion and pointers to > > them under some handbook entry > > > ... > > There's a man page for it :-) > > mdoc.samples(7). Now tell me that that's not intuitive. And in /usr/share/examples/mdoc there are three example templates for section 1, 3, and 4 manual pages. - Sections 1, 6 and 8 are all pretty much the same (user commands, games, administrator commands). - Sections 2 and 3 are pretty much the same (system calls and library functions). - Section 4 is used to describe external kernel interfaces. The individual formats can vary. The most common format is defined in example.4. - Section 5 is used to describe file formats, and due to the individual requirements of each different man page, there really isn't a general purpose template that would cover most cases. What I usually do for this section is to find another man page that I want mine to look like and edit it to suit my taste. - Section 7 is for misc. documentation. Format varys with what is being documented. - Section 9 is similar to section 2, with a sprinkling of section 4 in some cases, and then some more depending on the interface. Again, for something fancy, look for man page that has all of the different sections you want in your own man page and edit to taste. Also refer to mdoc.samples(7) and mdoc(7). mdoc(7) briefly describes all of the different mdoc macros. mdoc.samples(7) describes them all, along with examples of how each one should be used. As someone who has written a number of manual pages for FreeBSD, I think that for most things the examples in /usr/share/examples/mdoc should serve most would be man page writers fine (I use them). For more complex man pages, I usually just grab an existing man page and edit to tase. -Mike -- Mike Pritchard m...@freebsd.org or m...@mpp.pro-ns.net To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
