Re: [PATCH] adding two new options to 'cp'
On Wed, Jul 26, 2006 at 08:51:13PM -0700 I heard the voice of Julian Elischer, and lo! it spake thus: I've always used: find . -depth |cpio -pdlmv $dest While we're in workarounds, I fake with: % cat ~/bin/tarcp.sh #!/bin/sh cmd1=tar -cf - -C $1 . cmd2=tar -xvpf - -C $2 echo $cmd1 | $cmd2 $cmd1 | $cmd2 (which has the twin advantages of telling me what it's doing as it goes, and using two processes so it can pound source and dest disks in full parallel) -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: disklabel differences FreeBSD, DragonFly
On Thu, Jul 27, 2006 at 05:34:23PM -0400 I heard the voice of John Baldwin, and lo! it spake thus: On Thursday 27 July 2006 16:58, Mike Meyer wrote: Right. I typically install / and /usr as distinct files systems for just that reason (/ and /usr have different backup recovery strategies and I use dump, so that's why they are two partitions). So why does / need to be different from /var, /usr different from /usr/X11R6 and /home different from /usr/local? Seriously now - what I just described is my typical install. In my case I still have /home in /usr/home, but I should start making it separate in the hope that I could mount /usr read-only most of the time reducing the time it takes to fsck when I crash my test machines. I have / and /usr [sometimes one partition] mounted read-only on many of my systems. I like the peace of mind of KNOWING nothing'll go wonky on 'em on a crash, I like the shorter fsck times, I kinda like knowing there's that extra (very thin, but still extant) layer of protection against a lot of automated attacks... And, darnit, it just feels cleaner. I tend to have separate /var, /tmp, /home, and /usr/local which are kept rw since they have live and constantly-fiddled data on them, but everything else generally ends up ro since I only need to write them at specific discrete times. Out of the 11 partitions (multiple disks) on my workstation, only those 4 are generally rw. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: top delay value
On Wed, Jan 31, 2007 at 03:42:26PM +0100 I heard the voice of Oliver Fromme, and lo! it spake thus: Bottom line: Disabling zero-delay in top doesn't buy you anything at all. Meanwhile, you still can't zero-delay unless you're root. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: One method to recover a lost root password
On Sat, Mar 17, 2007 at 06:49:02AM +0100 I heard the voice of Soeren Straarup, and lo! it spake thus: On Fri, Mar 16, 2007 at 08:45:30PM -, Derekj Tourneo wrote: now edit the master password file vi /mnt/etc/master.passwd Try: vipw -d /mnt/etc It automaticly updates the right db(s) # chroot /mnt passwd root -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVIDIA FreeBSD kernel feature requests
On Fri, Mar 30, 2007 at 10:16:37AM +0200 I heard the voice of MOUILLE Jean Pierre Ext OF/DT, and lo! it spake thus: . 1 RAID 5 for data on nForce chip, with 3 maxtor/seagate 250 GB disks (~450 GB data) ataraid(4): CAVEATS RAID5 is not supported at this time. Code exists, but it neither uses nor maintains parity information. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: System Drops to manual mount root prompt after HDD duplication
On Tue, May 15, 2007 at 08:20:09AM +0200 I heard the voice of Dag-Erling Smørgrav, and lo! it spake thus: David Cramblett [EMAIL PROTECTED] writes: Dag-Erling Smørgrav [EMAIL PROTECTED] writes: What's in your /boot.config and /boot/loader.conf? I have no boot.config. [EMAIL PROTECTED] /]# cat /boot/loader.conf # -- sysinstall generated deltas -- # userconfig_script_load=YES Beats me... I can't even remember what userconfig_script is supposed to do. Note that support for 5.2.1 ended on July 31, 2004. Neither can I, but last weekend I upgraded some 4.x boxes to 5.x and then 6.x, and with the 5.x loader they croaked before booting until I took those userconfig_script_load lines out. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: boot loader
On Fri, Oct 26, 2007 at 01:47:04PM -0700 I heard the voice of Doug Barton, and lo! it spake thus: You could theoretically install onto a local system, tar it up, then unpack it in the unused partition on your remote machine, yes. However in order to set the new slice bootable you'd have to then use the disk editor, and if you get even one thing the tiniest bit wrong, you've bricked it. Actually, you may be able to talk the 4.x loader into loading and booting off the created 6.x partition. That would save disk editing. Still, you only get one shot at it without console access. But you said you have a serial port, so you could stuff a serial console on it, which gives you lots more safety. I moved a couple 4.x machines to 6.x remotely with just a serial console, and I think I only ended up needing to use the serial console on one machine where I didn't properly nudge the loader to look in the right place. Sure was glad to have it there, though. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: softupdates on root partition, no floppy
On Mon, Jul 19, 1999 at 05:25:06PM +1000, a little birdie told me that Stephen McKay remarked I gave up using soft updates on root because of the delayed delete behaviour. I kept filling up root while updating kernels. It doesn't gain you much on little used file systems anyway. So, I recommend people leave root alone. No, don't leave it alone, make it even SLOWER than usual! /dev/da0s1a on / (local, synchronous, writes: sync 114 async 3850) Question of the day: Why do I have async writes on a sync partition? -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ FutureSouth Communications |ISPHelp ISP Consulting "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: softupdates on root partition, no floppy
On Mon, Jul 19, 1999 at 11:25:16PM -0500, a little birdie told me that David Scheidt remarked On Mon, 19 Jul 1999, Matthew D. Fuller wrote: Question of the day: Why do I have async writes on a sync partition? Because only meta-data writes are done synchronously. Data is still done asynchronously. Even with SYNC mounts? (Not 'default', explicit 'sync'. It takes quite noticeable amounts of time to, for instance, install kernels.) From fstab: # DeviceMountpoint FStype Options DumpPass# /dev/da0s1a / ufs rw,sync 1 1 -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ FutureSouth Communications |ISPHelp ISP Consulting "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD: the stealth OS?
On Thu, Jul 22, 1999 at 09:51:38AM -0700, a little birdie told me that Matthew Dillon remarked I love the quote by Matthew Fuller at the end: "There's a lot of things that Linux is 'better' at, and a lot of things FreeBSD is 'better' at, and a lot of those things can easily fluctuate on a daily or weekly basis," said Fuller, who maintains a Linux vs BSD Web page. "Thus, any definitive narrow statement that can be made is usually obsolete before anyone hears it.". Perfect! Thank you, my fans! Please leave your monetary contributions in the hat on your way out; -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ FutureSouth Communications |ISPHelp ISP Consulting "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: No MAXUID ?
On Fri, Jul 30, 1999 at 09:13:52AM -0700, a little birdie told me that Mike Smith remarked I think that the administrator should be forced to override the warning manually to indicate that they are aware of the issues they are getting themselves in for, or at the very least that there should be some very serious warnings placed in the relevant manpages (mount_nfs, passwd(5), vipw, etc) covering these issues.a How about a bit of a compromise on it? Make pwd_mkdb just spew a warning like --- WARNING: UID(s) over X detected, may cause problems. --- by default, with a flag (-v?) to list the specific ones causing problems. Warning in manpages are, of course, always a Good Thing. -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ FutureSouth Communications |ISPHelp ISP Consulting "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: async v. sync v. default mode on ufs
On Thu, Aug 19, 1999 at 02:15:15PM +0900, a little birdie told me that Daniel C. Sobral remarked Larry Lile wrote: /dev/wd0s1f on /var (asynchronous, local, noatime, synchronous, writes: sync 93 async 216) procfs on /proc (local) /var looks questionable... Indeed. :-) I'm still looking for a 'splanation for this one: /dev/da0s1a on / (local, synchronous, writes: sync 34 async 954) ^^^ ^ I don't WANT async writes! -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ FutureSouth Communications |ISPHelp ISP Consulting "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: async v. sync v. default mode on ufs
On Thu, Aug 19, 1999 at 04:40:43PM -0700, a little birdie told me that Julian Elischer remarked That one looks like a bug, either in reporting them or in doing them.. /dev/da0s1a on / (local, synchronous, writes: sync 34 async 954) what version are you running? FreeBSD 4.0-CURRENT #1: Mon Aug 9 19:22:55 CDT 1999 -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ FutureSouth Communications |ISPHelp ISP Consulting "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Async NFS exports?
[ Caveat: I'm making this up as I go along ] On Fri, Aug 20, 1999 at 01:13:06PM -0500, a little birdie told me that Steve Ames remarked I asked this on stable but didn't get a response... Would I get any performance increases by mounting NFS exported partition as Async? Would my soul be tormented in purgatory for doing it? Just to be clear... I am wondering if mounting (on the NFS _server_) a partition (that is exportable) as async will have any performance benefits to the NFS clients? As a first guess, probably not unless you have a large number of active clients. Any modern hard disc will outperform ethernet/fast ethernet, especially for larger read/writes. For large numbers of smaller operations, or when there is a large number of simultaneous outstanding requests from clients, maybe. I'd say watch the disc itself (iostat is your friend), and if it's pegged (especially large numbers of tps) async might buy you some increase. -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ FutureSouth Communications |ISPHelp ISP Consulting "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: arch@freebsd.org
On Thu, Oct 07, 1999 at 11:40:04PM +0900, a little birdie told me that Daniel C. Sobral remarked Some people tried starting two different threads in that list. We failed in both cases. Though we don't know yet, I suspect it is simply a case of lack of subscribers. Hmmm... I WAS subscribed, and I never unsubscribed, and I even tried resubscribing a few times since I've never seen any traffic since January, and every time it told me I was still subscribed. Hmm... subscribe request just went through clean though. Was there a mass-unsubscription somewhere? -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ FutureSouth Communications |ISPHelp ISP Consulting "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: aio_read kills machine
On Tue, Oct 12, 1999 at 11:04:50AM +0930, a little birdie told me that Greg Lehey remarked What mailer are you using? It didn't quote the "From " at the beginning of the message, so David's message appeared as a separate message. If you're looking for it, sort your messages in mailbox order and it'll be the next message after Andy's original. He appears to be using Pine, and it quoted it just fine for me. And I do believe we're both using the same MUA, so I don't know where it burped on the way to you. -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ FutureSouth Communications |ISPHelp ISP Consulting "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Bad memory suspected
On Tue, Feb 01, 2000 at 05:01:55PM -0600, a little birdie told me that Chris Dillon remarked The last time I had a problem like this, it was because I put a P54C (Pentium-MMX) into a board only designed for the P53C (a.k.a standard ITYM P55C on a P54C board. -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
On Thu, Apr 12, 2001 at 02:24:36PM -0700, a little birdie told me that Matt Dillon remarked Without vmiodirenable turned on, any directory exceeding vfs.maxmallocbufspace becomes extremely expensive to work with O(N * diskIO). With vmiodirenable turned on huge directories are O(N), but have a better chance of being in the VM page cache so cost proportionally less even though they don't do any better on a relative scale. Speaking of vmiodirenable, what are the issues with it that it's not enabled by default? ISTR that it's been in a while, and most people pointed at it have reported success with it, and it seems to have solved problems here and there for a number of people. What's keeping it from the general case? -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Config devices not in machine
On Tue, Jul 03, 2001 at 12:26:58PM -0400, a little birdie told me that Mike Smith remarked I'm new to FreeBSD (come from the *gasp* System V and RTU world) so I hope this is the correct list for this. ( I'm sure I will be told if it's not :-} ) Is there ANY penalty for having a device in your config file that is not in your system?? It eats some RAM. It will waste a bit of time on the bootup probes (we're talking seconds, if that much) It takes a bit longer to compile (of course, far less than compiling 40 seperate kernels!) It's possible with some ISA devices that you can have conflicts, but you can generally work around those by disabling them in the kernel.conf either manually or from the boot -c editor (the changes were stored in the kernel binary in older versions, but anything reasonably recent will use the /boot/kernel.conf file). I am by no means the final authority on this, of course; but in my experience, you're going to see fractions of a percent increase in resource usage (primarily RAM) and some possible slight administrative overhead with conflict resolution. Far better solution, I'd say, than trying to customize everything. -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Bugfixes, security fixes, versions
The whole "Stable Branch" thread on -security gave me an idea that's been perculating for some time. Problem: We have security problems in (say) -STABLE. They get fixed. We post an advisory about it, giving correction dates for -STABLE and -CURRENT, and the associated cutoff in which releases are fixed and which are not. However, tracking dates on buildworlds etc is hard. I'm sure I'm not the only one who usually does build/installworlds on source at least a week old. I check it it, built it, and if it's clean, wait to see if anyone else has any problems with it. And since I tend to put off building the kernel until I install, the date uname gives isn't necessarily useful for checking this sort of stuff. Idea: In the version string (or maybe somewhere else convenient), start adding codes at each -RELEASE along a branch. So, say we find a bug in fingerd. It's in 4.1-RELEASE, fixed in 4.1-STABLE at some point, and fixed in 4.2-RELEASE. We could add an 'a' to the version string in -STABLE, so it will read out as "4.1-STABLE a". Find another bug and fix it, we have "4.1-STABLE b". Presumably, this would only apply to such things as security holes, and potentially showstopper bugfixes. If we really needed more than 26, we could go to capital letters, or doubled in parenthesis ...xyz(aa)(ab). I somehow doubt that'd be a big problem. Then, the version string could indicate what holes have been caulked up in the system they're running. They could be reset at each -RELEASE, so the advisory can say: 4.1 and below is VULNERABLE 4-STABLE with code 'a' is NOT VULNERABLE 4.2 and above are NOT VULNERABLE I can see a few flaws in this idea, but I figured I'd toss it out and let the wolves tear it to shreds ;) -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Editing /usr/include/*.h?
On Mon, May 03, 2004 at 05:13:04PM -0700 I heard the voice of Julian Elischer, and lo! it spake thus: On Mon, 3 May 2004, Kevin A. Pieckiel wrote: I want to modify sys/param.h to increase the value of MAXLOGNAME. I know I've done exactly this.. edit /usr/src/sys/param.h There's another #define in another header you have to edit. I'll think of it in a minute... Ah; UT_NAMESIZE in include/utmp.h. Used to do that all the time on 2.x.x to get 16 char usernames 8-) -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Memory Leak
On Sat, May 22, 2004 at 11:52:19AM -0700 I heard the voice of Tim Kientzle, and lo! it spake thus: The one problem I've had is that dmalloc.h redefines some standard functions, which can cause gcc to complain. I usually just have a flag in my Makefile to enable dmalloc (adding a -D to the cc line to enable including the header file which is inside #ifdef's, adding the linking of the library, etc), which turns off all -W flags. gcc's quiet about it then. Personally, I find its insistence that free(NULL); is an error to be far more irritating. There's a config flag for it somewhere in the compile process, though. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: smartmontools vs HP Smart Array 642 controller
On Thu, Feb 24, 2005 at 03:24:17PM -0600 I heard the voice of Chris Dillon, and lo! it spake thus: Your problem with smartmontools doesn't seem to be limited to the Smart Array 642, I just tried it on a DL380 G3 with the Smart Array 5i+ and got the same error you did. It appears to be a driver-specific problem. It's been failing on me on RELENG_5 since I updated from ~5.1 to ~5.3+, on an ahc controller: (pass5:ahc1:0:5:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (pass5:ahc1:0:5:0): CAM Status: SCSI Status Error (pass5:ahc1:0:5:0): SCSI Status: Check Condition (pass5:ahc1:0:5:0): UNIT ATTENTION asc:29,3 (pass5:ahc1:0:5:0): Bus device reset function occurred device Test Unit Ready [Operation not permitted] and the like. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
CVSup and Attic files
I've noticed some strange behavior suddenly out of CVSup. I refuse all Attic files in ports, and that doesn't seem to be working right all of a sudden. My best guess is that it's something due to the recent patch to cvsupd to handle INDEX issues, since I can't think of anything else that would make it suddenly change, but I don't know m3 or the cvsup source well enough to lay a guess as to why it's happening. Anybody else seeing anything like this? -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Should URL's be pervasive.
Oh god, as everybody else is saying, I can't believe I'm getting involved in this, but... On Fri, Aug 31, 2001 at 09:58:21AM -0700, a little birdie told me that Richard Hodges remarked Why not parse it literally? For instance, http://www.ufp.org would imply TCP, dest port 80, and host www.ufp.org. For ping, that would imply that I want to test the three-way handshake on whatever is listening on port 80 at www.ufp.org For traceroute, I want to send a series of TCP SYN packets to www.ufp.org, port 80 with increasing TTL values. Perhaps this No, it doesn't. http://www.ufp.org/ does NOT mean TCP port 80. www.ufp.org:80 means port 80, I don't know of any simple common way to say TCP. http://www.ufp.org/ means the host 'www.ufp.org' using the protocol 'http' with the TCP port 80 implicity as a result of the 'http'. Traceroute is not going to use HTTP. Ping is not going to use HTTP. Rpcinfo is not going to use HTTP. A mail client is not going to use HTTP (this one is perhaps debatable, but I'm sure as hell not going there). If you want to take a URI passed to 'ping', say, and parse out a hostname, that's one thing which I'm sure we could have endless disagreement about. But doing that is *NOT* parsing it as a URI. -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: syslogd and kqueue
On Sat, Oct 27, 2001 at 12:26:22AM -0400 I heard the voice of Mike Barcroft, and lo! it spake thus: Just to clarify. This is still a POLA violation. If a log file is pulled out from underneath syslogd(8), one wouldn't expect it to start logging again, even if the file was re-created. Just like one wouldn't expect it to create a new log file. Actually, one would. It always takes conscious effort for me to remember that syslog won't create non-existent logfiles. That means I have to go touch a bunch of files when, for instance, I'm setting up a jail(8). It seems extremely counter-intuitive to me that I can't just say Log to this file and have it start logging there, without me laying out a yellow brick road. Forget kqueue. Just an O_CREAT. -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tell gcc I have a i686
On Fri, Jan 04, 2002 at 12:02:03PM -0600 I heard the voice of Stephen Montgomery-Smith, and lo! it spake thus: I want to create a Makefile for a C program that includes some Pentium II specific inline assembler code. How do I tell the compiler whether we are compiling on a i686? Dunno, how well will your Pentium II specific inline assembler code run on my Pentium Pro? -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: complicated downgrade
On Fri, Jul 18, 2003 at 09:34:28PM -0700 I heard the voice of Terry Lambert, and lo! it spake thus: Your biggest problems are going to be the creation of the /dev, which will need to occur in an rc.local on reboot, Mightn't you be able to get away with this by something like: - Downgrade / to read-only - Mount / device rw on /mnt - Go into /mnt/dev and run the MAKEDEV -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: can we disable AAAA queries in the resolver ?
On Sat, Aug 02, 2003 at 09:59:18AM +0100 I heard the voice of
David Malone, and lo! it spake thus:
A significant number of these are ad servers, so after complaining
to Doubleclick and getting no response, I've told my local name
server that it is authorititive for doubleclick.net and given it
an empty zone. Since doing this I don't notice the problem any more.
I short-circuited to hosts and ipfw.
# ipfw show 2
2 14 864 reject ip from any to 127.0.0.2
# telnet ad.doubleclick.net 80
Trying 127.0.0.2...
telnet: connect to address 127.0.0.2: Permission denied
telnet: Unable to connect to remote host
('course, DNS is better with multiple machines. You could just burn a
single RFC1918 address for rejecting all the ad-type things)
--
Matthew Fuller (MF4839) | [EMAIL PROTECTED]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
The only reason I'm burning my candle at both ends, is because I
haven't figured out how to light the middle yet
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Does indent(1) have a KNF mode?
On Sun, Dec 07, 2003 at 10:25:39AM -0800 I heard the voice of Steve Kargl, and lo! it spake thus: Does indent(1) have a KNF mode? If not, does anyone have/know a set of command line switches that best approximates KNF? For the record, I tend to install GNU indent when I feel the itch, as it has significantly greater flexibility. You may have more luck there. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Wed, Jan 07, 2004 at 11:50:59PM -0800 I heard the voice of Avleen Vig, and lo! it spake thus: While it is indeed true that most machines since 1997 will support this CD format, please take in to account: And, further, some of us don't have (and don't want) CD burners, and even if we had 'em, don't want to burn (no pun intended ;) a CD blank just to install an OS, when we can just (re-)use 2 floppies and do it across the LAN from a local FTP mirror, which is as fast as a CD drive anyway. It seems to me that we could split more out into modules, and/or add more disks of modules (maybe categorize a storage device modules disk, a network drivers modules disk, etc, keeping just the more common devices in the main kernel). Last I saw, the current system only created a single modules disk, which was a godsend to a kernel overflowing one disk, but as we add more and more stuff becomes another, albeit larger, noose. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, Jan 08, 2004 at 02:05:14AM -0700 I heard the voice of Scott Long, and lo! it spake thus: For 5.x we already have a 3rd floppy that is dedicated to modules. Unfortunately, it doesn't work nearly as well as it should because there is no way to activate it during the boot sequence; it can only be used once sysinstall is running. Also, it too is nearly overflowing. Well, that's why I suggest more. Have a network cards floppy, and a mass storage devices floppy, etc. We should be able to fit the half-dozen most common network cards, the ata drivers, and a half dozen of the more common SCSI drivers on the boot kernel. That'll get us far enough to be able to load the drivers off the other disks, as well as install with just that on many systems. It won't necessarily be the prettiest process, but I'm in favor of letting the floppies be a bit ugly, or even explicitly moving them to experienced users only status. I just find them far too convenient, as well as ubiquitous, to see them sent into the Great Bitbucket In The Sky yet. If somebody wants pretty and not have to fudge around to find the driver to load for my RAID controller, THEN let 'em download the CD :) -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, Jan 08, 2004 at 03:43:55AM -0700 I heard the voice of Scott Long, and lo! it spake thus: Well, regardless of how you label it, these floppies still require lots of care and feeding in order to work. We currently have no way to support multiple floppies in a convenient way. My hope is that, with this piece taken care of, the amount of care and feeding necessary to maintain it will be minimized. When adding new drivers, you'd have to stick their names in a list somewhere to be split out, but that's pretty minimal. It should help avoid all the juggling we keep having to do to manage the size. This can be fixed in a variety of ways that range from fragile hacks to wonderful designs, but it still requires someone to put forth the effort. My offer for a 'floppy maintainer' is quite sincere; I hope that someone takes an interest and steps up to the challenge. I have some interest in this, to be sure. However, every time I've ventured into src/release/ in the past, I've come away with an intense desire for absinthe. I've never successfully built a release, and it's been my impression that you can't just build the floppies, you have to build the full release to have everything in place to build them. That takes a huge chunk of disk space (to say nothing of _TIME_! Just building the kernel and modules takes the better part of a half hour), which are two things in chronically short supply. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, Jan 08, 2004 at 07:36:10AM -0800 I heard the voice of Avleen Vig, and lo! it spake thus: If I understand you right.. A floppy boot, which loads the absolutely basic stuff (network drivers, and some easy way to config the network) and then goes and grabs the installer would otherwise be on the current floppies and boots it? Many (most?) Linux dists do this for floppy installs. I've come around to thinking it a better and better idea lately. It makes it easy to have much more bloa... er, featureful installers, particularly more graphical ones, since you're no longer limited by the size of a floppy. And even cheap DSL is faster than a floppy drive for loading it, to boot (no pun ;). And you can even provide for loading it off a local CD, if you have a CD drive you can't boot from. The downside is that writing such a beast is a lot more work... -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, Jan 08, 2004 at 03:36:42PM -0700 I heard the voice of Scott Long, and lo! it spake thus: Unfortunately, there are two problems with this. Now, The first is that it runs after the kernel has already booted, so SCSI devices that are handled by drivers on this floppy won't get probed. This I hadn't known. Why is that? I thought when you loaded a module it pulled up the driver and probed the hardware, which included scanning any busses on it. The second is that forcing the user to know which driver is appropriate for their hardware is not very good form. This is one of those things I list under the category of letting floppy installs be a bit ugly, or 'experienced-users only'-labelled. There are several documents linked off of http://www.freebsd.org/releng that describe how to build a release. It's not nearly as arcane of a process as it used to be 5 years ago. The biggest barrier to entry is probably disk space. You'll need a good 5GB free to hold the CVS repo, chroot environment, and resulting bits. Well, I've got the CVS repo, though boy, has *THAT* ever grown since I built this system; I had to trim it down to only src and ports, and even so: /dev/da1s1e 2032623 1769089 10092595%/usr/cvs Of course, I left out the ports and docs parts of the release last time I tried (which was in fact about 5 years ago ;), though I had all kinda of troubles with parts of THAT, too. But still, I don't have even a tenth that much hard drive space around. Yes, to build the floppies you need to build most of the release, but once you've built the release, you can back-step and rebuild the floppies at will. And building the whole release is quite an ordeal on a Pentium Pro :) Still, I'm willing to donate some time and brain to the problem, since apparently I kinda care about it. It seems to me that the probing problem above is the biggest problem from a real coding POV; the rest is mostly just a whole heck of a lot of implementation, and inconvenience from the usability standpoint. That's a breaking point. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Fri, Jan 09, 2004 at 05:50:59PM +1030 I heard the voice of Daniel O'Connor, and lo! it spake thus: I don't necessarily agree here - I think sysinstall is a better place because it's much much easier to write stuff for it than the loader. In the example you mention the only reason to use the loader is because the SCSI subsystem won't reprobe when a new SCSI bus comes online which sounds like a bug. Indeed. I think it's actually (specifically and as a class) the sort of bug/feature that very much impacts on the floppy situation, since it prevents us from using an otherwise open road to move stuff around. Even if we have to write some code in sysinstall or its successors to trigger the rescan from userland (ie, the 'camcontrol rescan' point), I think that's a reasonable road (and likely the easier way). But that's a bit out of my depth. Well, except when mfsroot.gz becomes too large to fit on a single floppy. Right now it is about 90k away from that. What happens when mount_nfsv4 gets put on there? John Baldwin and I already spat ent a day over the holiday break making the mfsroot.gz image fit given the new requirements created by having a dynamic root. However, given your example above, I would just put mount_nfsv4 on another floppy, although if sysinstall (or it's replacement) is too large, there will need to be the ability to load N floppy images into memory. This is that situation where the fetch installer program thingy from install media on the fly solution comes into play. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Fri, Jan 09, 2004 at 12:48:55AM -0700 I heard the voice of Scott Long, and lo! it spake thus: Daniel O'Connor wrote: BTW Does camcontrol rescan cause the devices to be detected? Perhaps sysinstall could be enhanced to perform this duty as part of it's reprobe machinations. See my comment about blowing out the mfsroot.gz file. If you're not careful with this one then you'll wind up pulling in libcam, which will certainly create a size problem. # $FreeBSD: src/release/i386/boot_crunch.conf,v 1.56 2003/01/23 08:30:47 ru Exp $ [...] progs [...] camcontrol [...] libs [...] -lcam [...] -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Fri, Jan 09, 2004 at 02:23:58PM -0700 I heard the voice of
Scott Long, and lo! it spake thus:
Dag-Erling Sm?rgrav wrote:
yes, we need something like
struct pci_device_info {
uint32_tpciid;
charbrand[64];
charmodel[64];
} my_supported_devices[] = {
{ 0x12345678, Acme, Nutcracker 2000 }
};
which is placed in a separate ELF section so we can extract it from
the module.
except it needs to be flexible enough to support other buses than PCI
(SBUS, USB...)
DES
Yeah, this is a good suggestion, the only problem being in making it
flexible enough to not be a burden on the drivers. Many drivers
keep one or more flag elements in their tables to flag hardware than
needs special attention. I'm sure that there are also countless other
pieces of state that drivers would want to associate with a table like
this.
I was poking around a bit (in my completely kernel-fu-lacking way) at
this last night. For one thing, we could avoid the struct definition,
and instead just mandate a few fields in the structure with given names
as above. Then, write a little helper .c file with a main() that goes
through the array (with the name given as a preprocessor -D or something)
and spits the info out into a text file. Compile it up and run it for
each module as we compile it, and assemble the results in a big reference
file. Then, a userland program (like sysinstall, in this case) can
easily poke through that text file to find and describe the drivers for
devices found.
I also was thinking that perhaps we should just stick the vendor/model
ID's (and maybe submodel and bus, too) into a string and export it via
sysctl; that was we don't have to use another tool or manually grub
around /dev/pci and whatever other buses there might be, to identify
devices pining away for a driver to mate with.
--
Matthew Fuller (MF4839) | [EMAIL PROTECTED]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
The only reason I'm burning my candle at both ends, is because I
haven't figured out how to light the middle yet
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [call for helpers!] Tuning for the Beaver Challenge
On Mon, Feb 09, 2004 at 07:27:08PM +0100 I heard the voice of Dag-Erling Sm?rgrav, and lo! it spake thus: CPU_FASTER_5X86_FPU is not likely to have any positive impact on performance, and fairly likely to render the system unbootable. I would guess just from the name that this (and some similarly named options) apply only to Cyrix 5x86 processors. Somehow, I don't think you'll run into too many of them in benchmarks these days. Just a hunch. CPUTYPE ?= pentiumpro I recall a thread somewhere recently about pentiumpro being decidedly suboptimal for some new CPUs. Although, on 4.x with the older version of gcc, it may not matter. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Odd ACL question
On Tue, Feb 10, 2004 at 11:38:46AM +0100 I heard the voice of Harti Brandt, and lo! it spake thus: So if you restore a backup that is say, half a year old, you may well have files that belong to no known user, even if restoring to the same system. I suppose that mapping them to a well known user (not necessarily 'nobody') and doing some clever 'find' afterwards would find these files. find -nouser -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding 'realclean' target to /usr/src/Makefile
On Sun, Feb 15, 2004 at 09:20:56AM + I heard the voice of Bruce M Simpson, and lo! it spake thus: It would be helpful if it were pointed out in documentation somewhere that the path to the compile and source directories, when doing NFS kernel installs, has to be identical to those which were in effect on the build box due to the treatment of MAKEOBJDIRPREFIX during the modules build (and subsequent modules/* path creation). And, last time I tried it (which admittedly was a long time ago, so grab your salt grainer), the same applied to world builds too. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Mozilla sucking file descriptors
Has anybody else seen Mozilla just start munching file descriptors the
longer it runs? I've seen it with at least Phoen^WFirebird 0.6 and
the current Firebi^WFirefox. It just keeps going 'till it maxes out
the system. fstat(1) doesn't show much directly, but with -v it spits
a crapload of errors:
(ttyp4):{173}% fstat -v | grep -E 'unknown file type 5 for file [0-9]+ of pid 4697'
| wc -l
3472
(that being, of course, my current firefox PID)
File type 5 is a kqueue (according to sys/file.h). Why is Mozilla
eating an ever-increasing number of kqueue handles? Is this our
problem or theirs? Or is this something fixed since I last updated
(I'm on 5.1-RELEASE now)?
(In other news, thank heavens you can tweak kern.maxfiles on the fly!)
--
Matthew Fuller (MF4839) | [EMAIL PROTECTED]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
The only reason I'm burning my candle at both ends, is because I
haven't figured out how to light the middle yet
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mergemaster improvement (auto-update for not modified files)
On Fri, May 13, 2005 at 12:40:46PM +0400 I heard the voice of Denis Peplin, and lo! it spake thus: 2. Setup CVSup collection for subset of required files (is it possible?), and then keep this small collection up-to-date locally. src-etc cvs collection already here. One thing that I'm pretty sure has been brought up before would be that, for those of us who keep a local CVS repo mirror, it's easy and pretty cheap to check out even arbitrary revs to compare to what's currently there (and if you wanted to be REALLY overly-smart, you could even try automagically merging local changes ;) -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Slowing down an old program to run on a fast CPU?
On Fri, Jun 10, 2005 at 03:44:15PM -0700 I heard the voice of Mike Hunter, and lo! it spake thus: Is there a general-purpose approach to this kind of problem in the FBSD world? I can see myself writing a C program called `slow` that would take argv[1] as the factor ( 1) by which argv[2] should be slowed down by. It'd be tough. One way might be a wrapper program that SIGSTOP'd and SIGCONT'd the program with some pauses, but that would be incredibly nasty and probably not too pretty. A better way could would be to wrap the program with a library implementing sleep() and friends differently, so they pause for N times as long. But even that doesn't help when the programs don't slow themselves down. I guess the only general solution would be an API into the scheduler saying Don't give this program more than N% of the CPU, but I'm pretty sure we don't have one. It'd be neat, though... /usr/bin/too-nice-for-its-own-good8-} -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: JFS2 on freebsd
On Fri, Sep 09, 2005 at 12:28:39PM +0100 I heard the voice of Robert Watson, and lo! it spake thus: - Pretty recent work to get read-only reiserfs working (committed and in the CVS repository). Which, by the way, I just used earlier this week to pull data and configs and such off an old and unlamentedly dead Mandrake box onto its (6-BETA) FreeBSD replacement, and which worked well enough to have me quietly giggling while it copied8-} -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hosts.allow
On Sat, Oct 08, 2005 at 03:45:23PM -0400 I heard the voice of Chuck Robey, and lo! it spake thus: I'm not sure if it is, or is not, affecting my rpcbind. Someone else pointed out hosts_access(5). I just wanted to point out that unless you did something to it, it's probably not. The file is run through first-match, and the first non-comment line in the default file is: ALL : ALL : allow -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: system password's file
On Fri, Oct 14, 2005 at 06:54:26AM -0500 I heard the voice of
Sergey Babkin, and lo! it spake thus:
I don't know if it's fixed now or not.
I just converted a Mandrake box a month or so ago, which used MD5
hashes. Worked flawlessly.
Hm, considering the we'd like people to migrate from Linux to
FreeBSD, having such a conversion script/program (especially if
someone writes it for their own use anyway) in the base system would
make a lot of sense.
It's not that hard. Somebody mentioned an awk script. I slapped it
together in perl in about 5 minutes. I'll bet it's in /tmp
somewhere...
#!/usr/bin/perl -w
use strict;
# First, suck in the shadow
my %passes;
open(SHADOW, shadow) or die Can't open shadow: $!;
while(SHADOW)
{
chomp;
my ($user,$hash,@dummy) = split(/:/);
#print(Adding SHADOW: '$user' - '$hash'\n);
$passes{$user} = $hash;
}
close(SHADOW);
# Now get the main data from the passwd
my @users;
my %uhash;
open(PASSWD, passwd) or die Can't open passwd: $!;
while(PASSWD)
{
chomp;
my ($user, $dummy, $uid, $gid, $gecos, $homedir, $shell)
= split(/:/);
my %thisuser;
#print(Adding PASSWD: '$user' ($uid,$gid) - '$gecos', $shell in
$homedir\n);
$uhash{$user}-{user} = $user;
$uhash{$user}-{uid} = $uid;
$uhash{$user}-{gid} = $gid;
$uhash{$user}-{gecos} = $gecos;
$uhash{$user}-{homedir} = $homedir;
$uhash{$user}-{shell} = $shell;
push(@users, $user);
}
close(PASSWD);
# Gen up a BSD master.passwd file
foreach my $user ( @users )
{
printf(%s:%s:%s:%s::0:0:%s:%s:%s\n,
$uhash{$user}-{user},
$passes{$uhash{$user}-{user}},
$uhash{$user}-{uid},
$uhash{$user}-{gid},
$uhash{$user}-{gecos},
$uhash{$user}-{homedir},
$uhash{$user}-{shell});
}
--
Matthew Fuller (MF4839) | [EMAIL PROTECTED]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nvi for serious hacking
On Mon, Oct 24, 2005 at 07:03:25AM +0200 I heard the voice of Andreas Klemm, and lo! it spake thus: Most favourite example: I personally still get mad if it comes to the u undo key. I miss :N. You have to :split and then :n separately. Standard vi lets you toggle your last change by hitting u. From my experience you cannot recover from such a mistake. You need redo (^R) to do the same in vim. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Very slow writing to SATA disk
On Fri, Oct 28, 2005 at 01:18:03AM -0400 I heard the voice of Mikhail T., and lo! it spake thus: According to smartctl, the drive runs at 56C during the copying. Its idle temperature seems to be 54C. That sounds a little high to me. Smartctl has been weird lately, and it only shows temp on one of my drives, but it (7200RPM 9gig SCSI) is showing 32C. The higher density probably burns a little more power, but half again the temperature? -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: poor fdc(4) performance
On Sat, Nov 12, 2005 at 04:44:18PM +0900 I heard the voice of Pyun YongHyeon, and lo! it spake thus: Yes, it could be. But I think the machine is fast enough to read sequential blocks. Try running it without SMP. There may be enough happening in the MP locking bit that you end up falling behind. I remember noticing crap fdc performance (without larger block sizes) on my dual PPro a little while back. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
On Wed, Dec 21, 2005 at 06:01:37PM +0200 I heard the voice of Juhana Tahvanainen, and lo! it spake thus: how about: FreeBSD-Handbook-General is rather fixed once ready, only maintenance needed is when some future release doesnt support something anymore, that is removed and moved to FreeBSD-Handbook-BRANCH.x. Difficult to manage. You have to remember or know which branches to backport stuff to, and you can't then say OK, we won't bother with 3.x anymore, but Handbook-3.x will remain around not needing further work for people using it, as future changes might not get pushed back. It would probably be easier using something like marked sections in a single handbook to separate out version-specific stuff from more general stuff; that way, at least it's all in one place, and you could just generate handbooks for any given branch off one source. Of course, it can get ugly to look at, too.. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
On Sun, Dec 25, 2005 at 01:46:15PM -0500 I heard the voice of Charles Sprickman, and lo! it spake thus: In fact, I'm pretty sure 4.11 can be installed with a USB keyboard. I may be imagining that though... Well, I'm pretty sure I didn't imagine installing 6.0 last month with a USB keyboard. Of course, the loader didn't grok it, but... -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
On Mon, Dec 26, 2005 at 02:15:52PM +1030 I heard the voice of Kris Kennaway, and lo! it spake thus: The loader groks it just fine when you choose the 'boot with USB keyboard' boot menu option ;-) How can I choose a menu option in the loader when the keyboard doesn't work in the loader? :p -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
On Tue, Dec 27, 2005 at 12:57:58AM +1030 I heard the voice of Kris Kennaway, and lo! it spake thus: Perhaps a BIOS option. I've never encountered a system with USB keyboard that did not work in the loader. The emulation or whatever it was was set in the BIOS. And it worked in the BIOS. Worked when the OS got up to sysinstall, too. Just wouldn't work for the loader. Luckily, I didn't need to do anything but wait for it to boot, but I figured the BIOS was laughing at me behind my back... -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
On Tue, Dec 27, 2005 at 01:28:23AM +1030 I heard the voice of Kris Kennaway, and lo! it spake thus: Matthew D. Fuller wrote: The emulation or whatever it was was set in the BIOS. And it worked in the BIOS. Worked when the OS got up to sysinstall, too. Just wouldn't work for the loader. What happens if you turn it off? Then it still didn't work in the loader, and wouldn't work for the BIOS either (so I had to plugin a PS/2 keyboard to turn it back on). I don't think I let it boot long enough to see if the keyboard worked in sysinstall in that case; I presume it would. And the system's in production now, so I can't really fiddle with it anymore. It's got a Biostar (blech!) Socket A motherboard. ACPI APIC Table: VKT400 AWRDACPI http://www.biostar.com.tw/products/mainboard/board.php?name=M7VIG%20400%20(7.x) -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: increasing dd disk to disk transfer rate
On Thu, Jan 12, 2006 at 10:48:38AM +0100 I heard the voice of Christoph Kukulies, and lo! it spake thus: dd if=/dev/ad2 of=/dev/ad3 conv=noerror Give it a bigger blocksize (say, bs=1m or so) and it'll go a **LOT** faster. My motherboard is an ASUS P4S8X with an on board promise controller (currently not in use). System disk is on IDE1 and the two 80GB disks are master/slave on IDE2 bus. You'll get much better results by having each drive be master on its own bus. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: speed up port compiling using RAM (tmpfs) ???
[ Cc trim a bit ] On Fri, Jan 20, 2006 at 08:53:11PM -0500 I heard the voice of Kris Kennaway, and lo! it spake thus: In order to do better you either have to: This is something that may be easier to: 3) Implement in portupgrade or portmanager or some such higher-level tool in a language that gives a little more flexibility than make, and which is already apparently pulling in most of the information it may need to do the job. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: speed up port compiling using RAM (tmpfs) ???
On Sat, Jan 21, 2006 at 03:23:21PM -0500 I heard the voice of Kris Kennaway, and lo! it spake thus: On Sat, Jan 21, 2006 at 10:07:39AM -0600, Matthew D. Fuller wrote: This is something that may be easier to: 3) Implement in portupgrade or portmanager or some such higher-level tool in a language that gives a little more flexibility than make, and which is already apparently pulling in most of the information it may need to do the job. You still have the same issue as 1). [ 1 == building dependancy tree to know what depends on what ] Yes, but portupgrade and friends already do most of that, so they can upgrade stuff in order. The biggest thing it seems like portupgrade (which is the only one I'm personally familiar with) lacks is that it doesn't of itself find out which of these dependancies are already installed, and lets the ports tree itself recurse down. It sounds, from reading the emails, like the script dougb has been putting together does this, though. Given that capability, and the information portupgrade builds (from all-depends-list, I think?) to determine which order to upgrade things in, it seems like it would have right there most of what it needs. There are still issues like after you start building something and it does the make config and the like to handle (as well as terminal arbitration issues with multiple possibly interactive compiles going at once), of course. Not an easy or trivial thing to do even with all that, certainly, but probably easier in perl/ruby/C/etc than in make... -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: speed up port compiling using RAM (tmpfs) ???
On Sun, Jan 22, 2006 at 08:09:56AM +1100 I heard the voice of Peter Jeremy, and lo! it spake thus: Given that a port's dependency tree can depend on the options it is invoked with, it would be nicer if the dependency tree was generated dynamically, rather than pulled out of the latest INDEX file. I'm pretty sure it _is_, since portupgrade finds things related to OPTIONS and such for me, and I don't blow multiple hours on INDEX builds. I'm pretty sure it uses all-depends-list (or one of its siblings). -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: NetBSD disk backup over network
On Tue, Mar 07, 2006 at 08:33:37AM -0600 I heard the voice of Sergey Babkin, and lo! it spake thus: You can easily save the stream of updates as a redo log (well, that's the idea I've been running around with). Isn't that what the gjournal SoC thing was about? -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Keyboard Boot Disable
On Tue, Apr 25, 2006 at 06:27:53PM -0400 I heard the voice of Lucas Holt, and lo! it spake thus: I worked with someone once that said they blew out the ps/2 port on the motherboard. I've seen this happen several times. Some boards were later revived by judicious use of a soldering iron, but not all. These days, I'd think USB keyboards would be easier than KVM switches. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 3.3 to 4.5 remote upgrade possible?
On Mon, Mar 04, 2002 at 11:03:47PM -0500 I heard the voice of Jim Durham, and lo! it spake thus: Is this Mission Impossible? I have no one at the site that can do this. If I say make installworld is the whole thing going to come to a grinding halt? When I did a 2.2.8-STABLE to 4.3-STABLE upgrade, I ended having to do it in one broken-up step. First (and the only sane way, IMO) is to do the buildworld on a 4.x system; get all those lib conflicts and crap out of the picture. Then I installed the 4.x kernel, did the necessary frobbing (installing loader, re-disklabel -B'ing, sd-da renames in /var with mknod, etc), booted up the 4.x kernel, THEN did the installworld, mergemaster, reboot. Some issues I found: - Some apps (portmap in particular) caused no end of trouble when the 2.2 app ran under the 4 kernel. Like, kernel-panic type trouble. - Device renamings are a bitch. In theory, a 3-4 upgrade should be easier than this, since you don't I think need to do any device renaming, which solves a bunch of my problems right off. I'd still be pretty leery about doing it remotely, though. -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
[fullermd@over-yonder.net: Re: bug in pw, freebsd 4.5]
Come to think of it, -hackers may be the more appropriate forum for RFC'ing on this... - Forwarded message from Matthew D. Fuller [EMAIL PROTECTED] - From: Matthew D. Fuller [EMAIL PROTECTED] To: Daniel Sickels [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Date: Sat, 9 Mar 2002 04:52:25 -0600 Subject: Re: bug in pw, freebsd 4.5 User-Agent: Mutt/1.2.5-fullermd.1i Message-ID: [EMAIL PROTECTED] On Fri, Mar 08, 2002 at 12:43:51PM -0500 I heard the voice of Daniel Sickels, and lo! it spake thus: Multiple instances of pw making chanegs at the same time cause some rather horrid things to happen. The master.passwd file can be quite badly corrupted, or pwd_mkdb can fail. This bug is easily reproducable with a 1+ line master.passwd, using: pw useradd test1; pw userdel test1 ten times over in one process, and pw useradd test2; pw userdel test2 ten times over at the same time. The reason for this is that the only file pw(8) locks is /etc/master.passwd.new when it copies into it. It can't lock master.passwd, because that file will disappear and reappear in the middle of its work. I suppose in THEORY you could change the master.passwd - internal fudging - master.passwd.new - rename(master.passwd.new, master.passwd) into - ftruncate(master.passwd), master.passwd.new copy into master.passwd, but that seems rather ugly. I think the correct (well, the least incorrect, anyway) solution is to use an external lockfile for dealings with the passwd file. From a look at hier(8), /var/run seems the most appropriate place. pwd_mkdb(8) and vipw(8) would need to be made to use that location too, and I think pwd_mkdb(8) may need to have a flag added to NOT lock (since pw(8) calls pwd_mkdb(8) internally, it would have to hold the lock the whole time so as to avoid opening a race window). If anybody's interested, I could take a stab at hacking something together for this sometime over the next week or so. -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-bugs in the body of the message - End forwarded message - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gcc -O broken in CURRENT
[ Trim the CC's a bit ]
On Fri, Mar 15, 2002 at 04:00:08PM -0800 I heard the voice of
Terry Lambert, and lo! it spake thus:
Kenneth Culver wrote:
Other reasons I haven't even thought of yet 8-).
Yeah, I was just wondering if there were issues making us keep a.out stuff
in FreeBSD aside from the I wanna run 2.2.x programs issue.
Linking with third party a.out libraries.
Other reasons I haven't even thought of yet 8-).
(ttypa):{1078}% file /usr/local/lib/netscape/communicator-4.7.us.bin
/usr/local/lib/netscape/communicator-4.7.us.bin: FreeBSD/i386 compact
demand paged dynamically linked executable
Now, if you'd like to talk Netscape into building a version intended for
a version of FreeBSD newer than, say, 3 years, 3.5 months (approximately)
old...
--
Matthew Fuller (MF4839) |[EMAIL PROTECTED]
Unix Systems Administrator |[EMAIL PROTECTED]
Specializing in FreeBSD |http://www.over-yonder.net/
The only reason I'm burning my candle at both ends, is because I
haven't figured out how to light the middle yet
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: gcc -O broken in CURRENT
On Fri, Mar 15, 2002 at 08:53:16PM -0500 I heard the voice of Kenneth Culver, and lo! it spake thus: I didn't realize anyone still used netscape 4.x. It's so disgustingly unstable and slow. That it is. The problem, of course, is that all the alternatives are more unstable and slowER. #include rehash.h, see the thread we had on this a few weeks back on -chat. -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
PR's in need of a home
So, whose palm do I grease to get some PR's taken care of? ;-) - docs/31265 - Documentation (and adjustment) of cron allow/deny file formats Best (IMO, but then, I wrote it ;) patch at end of audit trail. - docs/35436 - Webpage update; don't push PAO Patch in PR - docs/35575 - pw(8) manpage update: document /var/log/userlog Patch in audit trail - bin/35505 - sed(1) feature: esed - sed -E bde doesn't like it. I like it, but not enough to fight more than casual criticism of it. If anybody else cares enough, it could be discussed; if not, the PR can just be closed. Enjoy :) -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bug in pw, freebsd 4.5
On Thu, May 02, 2002 at 05:10:00PM -0400 I heard the voice of Matt Simerson, and lo! it spake thus: On 5/2/02 4:27 PM, Geoffrey C. Speicher [EMAIL PROTECTED] wrote: On Sat, 9 Mar 2002 04:52:25 -0600, Matthew D. Fuller wrote: [in regard to multiple concurrent pw(8) processes hosing master.passwd] The reason for this is that the only file pw(8) locks is /etc/master.passwd.new when it copies into it. [snip] If anybody's interested, I could take a stab at hacking something together for this sometime over the next week or so. I'm interested. How did the stab go? I'm browsing archives and I can't find any more followups. I'm interested too. I've seen this problem (quite a few times) on a large system (1k-10k+) users. It only happens on systems being provisioned to via pw. Well, the stab didn't go because nobody was interested 8-) I looked at it a bit, but nobody expressed any interest, and my time ended up getting suckedup by other things. I actually had in mind some farther-reaching changes, which would (after 'fixing' pw) include potentially rewriting adduser(8) and friends to backend into pw to; sort of consolidate the user-management stuff a bit. I'll see if I can put some time over the next few days into delving into it and at least getting the first step (of making the locking work more usefully) work. What do people think of using the external lock file (well, I can't actually think of any OTHER way to do it, so...)? I'm thinking /var/run, but on the flipside just putting it in /etc might be cleaner. Comments? -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bug in pw, freebsd 4.5
On Thu, May 02, 2002 at 03:38:47PM -0700 I heard the voice of Jeff Jirsa, and lo! it spake thus: Feel free to correct me if I'm wrong, but /var/run seems like the more logical answer. Read-only / filesystems would have a hard time creating temp lock files in /etc. If nothing else, make it something that's easily configurable to avoid problems with read only filesystems. Well, read-only / filesystems would have a hard time creating /etc/master.passwd.new in the middle of pw's actions, too :) /var/run isn't a perfect choice, but it doesn't seem a bad one, and there's rather a bit of precedent for using it for state files, which I'd call a lock file (PID files, Apache stores some state, log/named sockets, etc). -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Locking the passwd subsystem (was Re: bug in pw, -STABLE [patch])
revision 1.46
diff -u -r1.46 Makefile
--- lib/libutil/Makefile8 May 2002 00:50:07 - 1.46
+++ lib/libutil/Makefile23 Jun 2002 13:31:01 -
@@ -8,7 +8,7 @@
CFLAGS+=-DINET6
SRCS= _secure_path.c auth.c fparseln.c login.c login_auth.c \
login_cap.c login_class.c login_crypt.c login_ok.c login_times.c \
- login_tty.c logout.c logwtmp.c property.c pty.c \
+ login_tty.c logout.c logwtmp.c pid_util.c property.c pty.c \
pw_util.c realhostname.c stub.c \
trimdomain.c uucplock.c
INCS= libutil.h login_cap.h
@@ -16,7 +16,7 @@
MAN+= login.3 login_auth.3 login_tty.3 logout.3 logwtmp.3 pty.3 \
login_cap.3 login_class.3 login_times.3 login_ok.3 \
_secure_path.3 uucplock.3 property.3 auth.3 realhostname.3 \
- realhostname_sa.3 trimdomain.3 fparseln.3
+ realhostname_sa.3 trimdomain.3 fparseln.3 pid_util.3
MAN+= login.conf.5 auth.conf.5
MLINKS+= property.3 properties_read.3 property.3 properties_free.3
MLINKS+= property.3 property_find.3
@@ -39,5 +39,6 @@
MLINKS+=login_auth.3 auth_checknologin.3 login_auth.3 auth_cat.3
MLINKS+=uucplock.3 uu_lock.3 uucplock.3 uu_lock_txfr.3 \
uucplock.3 uu_unlock.3 uucplock.3 uu_lockerr.3
+MLINKS+=pid_util.3 pid_begin.3 pid_end.3
.include bsd.lib.mk
Index: lib/libutil/libutil.h
===
RCS file: /usr/cvs/src/lib/libutil/libutil.h,v
retrieving revision 1.37
diff -u -r1.37 libutil.h
--- lib/libutil/libutil.h 8 May 2002 00:50:07 - 1.37
+++ lib/libutil/libutil.h 23 Jun 2002 12:35:30 -
@@ -82,6 +82,8 @@
struct sockaddr;
intrealhostname_sa(char *host, size_t hsize, struct sockaddr *addr,
int addrlen);
+int pid_begin(const char *pidfile, mode_t mode, int flags);
+int pid_end(const char *pidfile);
#ifdef _STDIO_H_ /* avoid adding new includes */
char *fparseln(FILE *, size_t *, size_t *, const char[3], int);
#endif
@@ -128,5 +130,8 @@
/* pw_scan() */
#define PWSCAN_MASTER 0x01
#define PWSCAN_WARN0x02
+
+/* pid_begin() */
+#define PID_NOBLOCK0x01
#endif /* !_LIBUTIL_H_ */
Index: lib/libutil/pid_util.c
===
--- /dev/null Sun Jun 23 08:44:01 2002
+++ lib/libutil/pid_util.c Sun Jun 23 07:34:28 2002
@@ -0,0 +1,176 @@
+/*-
+ * Copyright (c) 2002 Matthew D. Fuller [EMAIL PROTECTED]
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#ifndef lint
+static const char rcsid[] =
+ $FreeBSD$;
+#endif /* not lint */
+
+/*
+ * These functions are for maintenance of locking PID files
+ */
+
+#include sys/param.h
+#include sys/proc.h
+#include sys/uio.h
+
+#include errno.h
+#include fcntl.h
+#include signal.h
+#include stdio.h
+#include stdlib.h
+#include unistd.h
+
+#include libutil.h
+
+
+#define PID_LEN6 /* Currently only need 5 (0-99,999) */
+
+/*
+ * pid_begin: Open a PID file and write PID into it. If one already
+ * exists, try and track down the process which opened it; if it can't be
+ * found, proceed as if the file weren't even there.
+ */
+int
+pid_begin(const char *pidfile, mode_t mode, int flags)
+{
+ int procdead=0;
+ int lockfd;
+ int holding=0;
+ pid_t masterpid;
+ char *pidstr;
+ char readpid[PID_LEN+1];
+
+start:
+ if( (lockfd=open(pidfile, O_RDWR | O_CREAT | O_EXCL | O_EXLOCK,
+ mode)) 0 )
+ {
+ if(errno!=EEXIST)
+ return(-1); /* Preserve errno */
+
+ /* Open and find PID */
+ if( (lockfd=open(pidfile, O_RDWR | O_EXLOCK, mode)) 0
Re: ppbus questions
On Sun, Jun 23, 2002 at 12:15:01PM +0200 I heard the voice of Martin Faxer, and lo! it spake thus: i'm trying to write a driver for an old cd-rom drive that you connect to the parallel port. it is a shuttletech para drive 525. i don't have any driver docs or technical specifications but i believe that it uses some kind of a SCSI to parallel chipset. Perhaps you've already been over this, but have you tried just using (or altering) the vpo driver? It already provides something resembling a SCSI interface for parallel-port ZIP drives; it would seem the logical place to start. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Locking the passwd subsystem (was Re: bug in pw, -STABLE [patch])
On Sun, Jun 23, 2002 at 11:17:35AM -0400 I heard the voice of
Geoffrey C. Speicher, and lo! it spake thus:
5-minute window. Still unliklely, but not quite as unlikely as the
non-daemon scenario.
And it all goes out when window when kern.randompid=1, so it's kinda
moot.
Looks good from here. I've attached some minor patches (also relative to
src/) to pid_util.{3,c}. The first corrects some minor typos in the man
page and the second is to make pid_begin() work as advertised when read()
fails (set errno and return -1 rather than return errno).
Yes, I have a brain. No, really I do. I just don't have enough coffee
:)
(I haven't tested any of this yet either.)
I just slapped together a few quick test programs. Here's an updated
patch, incorporating your fixes, as well as a bugfix and an almost-bugfix
my testing showed up (hint: just because you ftruncate() to 0-length,
doesn't mean your offset becomes 0 too, dangit), and eliminated an extra
variable.
--
Matthew Fuller (MF4839) | [EMAIL PROTECTED]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
The only reason I'm burning my candle at both ends, is because I
haven't figured out how to light the middle yet
Index: lib/libutil/Makefile
===
RCS file: /usr/cvs/src/lib/libutil/Makefile,v
retrieving revision 1.46
diff -u -r1.46 Makefile
--- lib/libutil/Makefile8 May 2002 00:50:07 - 1.46
+++ lib/libutil/Makefile23 Jun 2002 13:31:01 -
@@ -8,7 +8,7 @@
CFLAGS+=-DINET6
SRCS= _secure_path.c auth.c fparseln.c login.c login_auth.c \
login_cap.c login_class.c login_crypt.c login_ok.c login_times.c \
- login_tty.c logout.c logwtmp.c property.c pty.c \
+ login_tty.c logout.c logwtmp.c pid_util.c property.c pty.c \
pw_util.c realhostname.c stub.c \
trimdomain.c uucplock.c
INCS= libutil.h login_cap.h
@@ -16,7 +16,7 @@
MAN+= login.3 login_auth.3 login_tty.3 logout.3 logwtmp.3 pty.3 \
login_cap.3 login_class.3 login_times.3 login_ok.3 \
_secure_path.3 uucplock.3 property.3 auth.3 realhostname.3 \
- realhostname_sa.3 trimdomain.3 fparseln.3
+ realhostname_sa.3 trimdomain.3 fparseln.3 pid_util.3
MAN+= login.conf.5 auth.conf.5
MLINKS+= property.3 properties_read.3 property.3 properties_free.3
MLINKS+= property.3 property_find.3
@@ -39,5 +39,6 @@
MLINKS+=login_auth.3 auth_checknologin.3 login_auth.3 auth_cat.3
MLINKS+=uucplock.3 uu_lock.3 uucplock.3 uu_lock_txfr.3 \
uucplock.3 uu_unlock.3 uucplock.3 uu_lockerr.3
+MLINKS+=pid_util.3 pid_begin.3 pid_end.3
.include bsd.lib.mk
Index: lib/libutil/libutil.h
===
RCS file: /usr/cvs/src/lib/libutil/libutil.h,v
retrieving revision 1.37
diff -u -r1.37 libutil.h
--- lib/libutil/libutil.h 8 May 2002 00:50:07 - 1.37
+++ lib/libutil/libutil.h 23 Jun 2002 12:35:30 -
@@ -82,6 +82,8 @@
struct sockaddr;
intrealhostname_sa(char *host, size_t hsize, struct sockaddr *addr,
int addrlen);
+int pid_begin(const char *pidfile, mode_t mode, int flags);
+int pid_end(const char *pidfile);
#ifdef _STDIO_H_ /* avoid adding new includes */
char *fparseln(FILE *, size_t *, size_t *, const char[3], int);
#endif
@@ -128,5 +130,8 @@
/* pw_scan() */
#define PWSCAN_MASTER 0x01
#define PWSCAN_WARN0x02
+
+/* pid_begin() */
+#define PID_NOBLOCK0x01
#endif /* !_LIBUTIL_H_ */
Index: lib/libutil/pid_util.c
===
--- /dev/null Sun Jun 23 11:44:00 2002
+++ lib/libutil/pid_util.c Sun Jun 23 11:50:59 2002
@@ -0,0 +1,178 @@
+/*-
+ * Copyright (c) 2002 Matthew D. Fuller [EMAIL PROTECTED]
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY
Re: Locking the passwd subsystem (was Re: bug in pw, -STABLE [patch])
And here's a run at Stage 2. This adapts a subset of programs to use the
pid_*() locking supplied. The attached patch updates: pwd.h, libutil
(libutil.h and pw_util.c), chpass (chpass.c), pw (pw.c), pwd_mkdb
(Makefile, pwd_mkdb.8, pwd_mkdb.c), vipw (vipw.c). This does NOT include
passwd(1), since that does its dirty work in PAM, which I definately
don't feel like delving into.
Note that this patch MAY be a little off when applied over the previous
patch; I'm working on them in seperate trees, to try and keep the stages
discrete. But a little manual fiddling should get them reconciled in
short order.
--
Matthew Fuller (MF4839) | [EMAIL PROTECTED]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
The only reason I'm burning my candle at both ends, is because I
haven't figured out how to light the middle yet
Index: include/pwd.h
===
RCS file: /usr/cvs/src/include/pwd.h,v
retrieving revision 1.12
diff -u -r1.12 pwd.h
--- include/pwd.h 9 Jun 2002 19:39:18 - 1.12
+++ include/pwd.h 23 Jun 2002 18:16:21 -
@@ -66,6 +66,9 @@
#define_PATH_MASTERPASSWD /etc/master.passwd
#define_MASTERPASSWD master.passwd
+#define_PATH_PWDLOCK /var/run/pwd.lock
+#define_MODE_PWDLOCK (S_IRUSR | S_IWUSR)
+
#define_PATH_MP_DB /etc/pwd.db
#define_MP_DB pwd.db
#define_PATH_SMP_DB/etc/spwd.db
Index: lib/libutil/libutil.h
===
RCS file: /usr/cvs/src/lib/libutil/libutil.h,v
retrieving revision 1.37
diff -u -r1.37 libutil.h
--- lib/libutil/libutil.h 8 May 2002 00:50:07 - 1.37
+++ lib/libutil/libutil.h 23 Jun 2002 18:38:18 -
@@ -95,6 +95,8 @@
intpw_init(const char *_dir, const char *_master);
char *pw_make(struct passwd *_pw);
intpw_mkdb(const char *_user);
+intpw_globlock(int);
+intpw_globunlock(void);
intpw_lock(void);
struct passwd *pw_scan(const char *_line, int _flags);
const char *pw_tempname(void);
@@ -124,6 +126,9 @@
#defineFPARSELN_UNESCCOMM 0x04
#defineFPARSELN_UNESCREST 0x08
#defineFPARSELN_UNESCALL 0x0f
+
+/* pw_globlock() */
+#definePW_NOBLOCK PID_NOBLOCK
/* pw_scan() */
#define PWSCAN_MASTER 0x01
Index: lib/libutil/pw_util.c
===
RCS file: /usr/cvs/src/lib/libutil/pw_util.c,v
retrieving revision 1.25
diff -u -r1.25 pw_util.c
--- lib/libutil/pw_util.c 8 May 2002 14:52:32 - 1.25
+++ lib/libutil/pw_util.c 23 Jun 2002 18:46:19 -
@@ -79,6 +79,7 @@
static char passwd_dir[PATH_MAX];
static char tempname[PATH_MAX];
static int initialized;
+static int globlocked = 0;
void
pw_cont(int sig)
@@ -163,6 +164,28 @@
}
/*
+ * Lock the password subsystem globally.
+ */
+int
+pw_globlock(int flags)
+{
+ int retval;
+
+ if( (retval=pid_begin(_PATH_PWDLOCK, _MODE_PWDLOCK, flags)) == 0 );
+ globlocked=1;
+ return(retval);
+}
+
+/*
+ * Unlock the global lock
+ */
+int pw_globunlock(void)
+{
+
+ return(pid_end(_PATH_PWDLOCK));
+}
+
+/*
* Lock the master password file.
*/
int
@@ -258,10 +281,10 @@
case 0:
/* child */
if (user == NULL)
- execl(_PATH_PWD_MKDB, pwd_mkdb, -p,
+ execl(_PATH_PWD_MKDB, pwd_mkdb, -p, -n,
-d, passwd_dir, tempname, NULL);
else
- execl(_PATH_PWD_MKDB, pwd_mkdb, -p,
+ execl(_PATH_PWD_MKDB, pwd_mkdb, -p, -n,
-d, passwd_dir, -u, user, tempname, NULL);
_exit(1);
default:
@@ -353,6 +376,11 @@
}
if (lockfd != -1)
close(lockfd);
+ if (globlocked != 0)
+ {
+ globlocked=0;
+ pid_end(_PATH_PWDLOCK);
+ }
errno = serrno;
}
Index: usr.bin/chpass/chpass.c
===
RCS file: /usr/cvs/src/usr.bin/chpass/chpass.c,v
retrieving revision 1.23
diff -u -r1.23 chpass.c
--- usr.bin/chpass/chpass.c 8 May 2002 00:54:28 - 1.23
+++ usr.bin/chpass/chpass.c 23 Jun 2002 18:42:25 -
@@ -258,6 +258,8 @@
case _PWF_FILES:
if (pw_init(NULL, NULL))
err(1, pw_init());
+ if (pw_globlock(PW_NOBLOCK) 0)
+ err(1, pw_globlock());
if ((pfd = pw_lock()) == -1) {
pw_fini();
err(1, pw_lock());
Index: usr.sbin/pw/pw.c
===
RCS file: /usr/cvs/src/usr.sbin/pw/pw.c,v
retrieving
Re: bug in pw, -STABLE [patch]
On Sun, Jun 23, 2002 at 11:32:54AM -0700 I heard the voice of
Paul Herman, and lo! it spake thus:
In fact, if you look at fileupdate(), you see that it already gains
an exclusive lock on the temp file, but not the original
/etc/master.passwd (if you will.) I think this is a bug, because
the original is getting modified (at least in name space), so that
should be locked while pw(8) is operating.
I'm not sure. Hm.
I think that MAY prevent some of the corruption cases. On the other
hand, we're really addressing a broader spectrum of issues here. The was
pw(8) manipulates the passwd database is rather different from how
chpass(1) or vipw(8) do it; this unifies it all (well, starts the
process). Also, looking down, it seems that pw(8) will ALWAYS try to do
a line-by-line copy of the temp file back into the main file, which would
be Bad Bad Bad (tm); it does this because using rename() all the time
loses the flock() lock. However, if we use this global locking, we can
dispense with that, and remove some code complexity, to say nothing of a
giant waste of time copying line-by-line.
I'm trying to kill several birds with as small a stone as I can; I've had
my eye on this whole subsystem for a while, and I'd really like to
re-center it all around pw(8). vipw(8) kinda has to be its own beast,
but chpass(1) and adduser(8)/rmuser(8) are prime candidates to be
reworked to use pw(8) for their dirty work.
Let's try this: updated patch for pw(8) including my global locking, the
addition of flock()'ing both old and new files (it's not quite necessary,
since it's all under a global lock, but it never hurts to double-check)
as in your patch, and removing the line-by-line copy and using rename()
all the time. (I suggest tabstop=4 or even =2; that file is *DEEP*)
--
Matthew Fuller (MF4839) | [EMAIL PROTECTED]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
The only reason I'm burning my candle at both ends, is because I
haven't figured out how to light the middle yet
Index: fileupd.c
===
RCS file: /usr/cvs/src/usr.sbin/pw/fileupd.c,v
retrieving revision 1.9
diff -u -r1.9 fileupd.c
--- fileupd.c 26 Oct 1999 04:27:13 - 1.9
+++ fileupd.c 23 Jun 2002 19:22:16 -
@@ -76,7 +76,8 @@
if (pfxlen = 1)
rc = EINVAL;
else {
- intinfd = open(filename, O_RDWR | O_CREAT, fmode);
+ intinfd = open(filename,
+ O_RDWR | O_CREAT | O_EXLOCK | O_NONBLOCK, fmode);
if (infd == -1)
rc = errno;
@@ -92,7 +93,8 @@
strcpy(file, filename);
strcat(file, .new);
- outfd = open(file, O_RDWR | O_CREAT | O_TRUNC |
O_EXLOCK, fmode);
+ outfd = open(file,
+ O_RDWR | O_CREAT | O_TRUNC | O_EXLOCK |
+O_NONBLOCK, fmode);
if (outfd == -1)
rc = errno;
else {
@@ -169,27 +171,24 @@
rc = errno; /*
Failed to update */
else {
/*
-* Copy data back into
the
+* Move data back into
+the
* original file and
truncate
*/
rewind(infp);
rewind(outfp);
- while (fgets(line,
linesize, outfp) != NULL)
- fputs(line,
infp);
/*
-* If there was a
problem with copying
-* we will just rename
'file.new'
-* to 'file'.
-* This is a gross
hack, but we may have
-* corrupted the
original file
-* Unfortunately, it
will lose the inode
-* and hence the lock.
+* Use rename() to
+move the new file
Re: bug in pw, -STABLE [patch]
On Sun, Jun 23, 2002 at 01:19:02PM -0700 I heard the voice of Paul Herman, and lo! it spake thus: I think you might have your infp confused with your outfp. It's not writing to the original live file, it's just writing the new temp file. That part of the code is OK. I'm talking about down around line 177 thru (unpatched), where it's copying back to the primary file. As it stands now (I hadn't realized in my prior reading) it's line-by-line'ing it: /* * Copy data back into the * original file and truncate */ rewind(infp); rewind(outfp); while (fgets(line, linesize, outfp) != NULL) fputs(line, infp); /* * If there was a problem with copying * we will just rename 'file.new' * to 'file'. * This is a gross hack, but we may have * corrupted the original file * Unfortunately, it will lose the inode * and hence the lock. */ if (fflush(infp) == EOF || ferror(infp)) rename(file, filename); else ftruncate(infd, ftell(infp)); which is Very Bad (tm) in that it's not very resilient against system crashes. The rename() solution is much safer. As for the giant lock, it would be like closing down the entire airport after someone finds a knife in the snack bar, and in my opinion an this is an unwise and brutal thing to do. No, it's more like closing the snack bar while you clean it, rather than closing the first steam tray while cleaning that, then the second steam tray, then the third booth on the left side, then... That way, when you open the snack bar, you know that the whole thing is clean (or, depending on your skill and work ethic, at least equally dirty ;). In many passwd-manipulations, the file can't be safely modified in-place, so it has to be done out-of-place, then atomically shoved in, which requires a rename() or the ilk; the downside is that you can't flock() the file in question and handle that easily. One also has to consider the impact with other programs, potentially not written by us, that modify things; a wrapper lock on changes to the auth information is really the only way to ensure consistency; otherwise, you can't REALLY be sure that the passwd and group files are in sync, to say nothing of preventing crashes from mangling things. Not to mention stale /var/run/ files that might be lying around... See the code I put in pid_begin() to handle just that case, that being the reason the function was written in the first place (otherwise, I could dispose of a lot of mess, and just use an empty file as a mutex for it). I do appreciate your work, but please don't commit this until the real issue is solved, and the dust settles. There still may be some use for it... plenty of time until the next release cycle. Commit? How would I do that? :P -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bug in pw, -STABLE [patch]
OK, this is the end for me today. I'm fairly sure, somehow, it's time to
get some sleep ;p
On Sun, Jun 23, 2002 at 03:51:46PM -0700 I heard the voice of
Paul Herman, and lo! it spake thus:
Moral of that story: This would mean for pw(8) that I can't update
the system passwords and the passwords in all my jails at the same
time. There is no reason to enforce that policy.
No, it means that (with configuration) you can only update them once at a
time in each jail.
I'm all in favor of adding options, either command line, or pw.conf (or
both) to put the lockfile somewhere else; -V ${dir} already makes pw(8)
read ${dir}/pw.conf instead of the default /etc/pw.conf, so we're 90% of
the way there already. Heck, I wouldn't be too worried about adjusting
the lockfile location based on -V automagically. I'm also not opposed to
adding an option to not bother with this locking; I already added one to
pwd_mkdb(8) (primarily because it's called from libutil's pw_mkdb(3),
which is called by vipw(8)... deadlocks suck). I just haven't done
either NOW; nor have I yet added options to 'block on the lock and keep
trying' (or decided to make blocking the default and have a switch for
non-blocking) - this is experimental implementation stage, after all.
I don't claim this is perfect for every case; I'm just taking aim at the
common case, where it's currently far too easy to accidentally screw
yourself in the foot.
Q: rename() is good, but you can't flock() the file in question
and handle it easily, can you?
A: Indeed, you can. flocks() are even preserved across renames.
Yes, I've seen that.
A: Agreed, this is a problem. However, no system in place will
prevent at any time anyone with the proper credentials from
doing:
I was aiming more at:
User A adds user with pw(8)
* pw(8) gets together stuff, internally adds user and group
* pw(8) builds homedirs, skel files, changes ownership
* pw(8) opens and locks master.passwd (and assorted temp files) and
starts rewriting
- User B adds group
% User B's pw(8) (or other) invocation adds group with GID that User
A's pw(8) had already assigned and chmod'd for user above
* User A's pw(8) either errors out leaving job half done, or adds group
with duplicate GID, or (not coded) backs out everything it's done and
starts over, or (ditto) backs out everything it's done and errors
back to User A, who screams and bitches and dumps User B into the
East River after sundown.
Similar situations can be thought up. My POV on this is that more than 1
file has to be coordinated here, so why not just make 1 file responsible
for the coordination? I don't care THAT much if it's called
/var/run/pwd.lock or /etc/passwd.lock or /kernel (I suggest testing the
latter on a scratch system). It just seems to me the simplest and least
error-prone way of doing it.
Yes, a lock on changes to the auth information is the only
way to ensure consistency, which is what this is all about,
but HOW to accomplish this issue at hand.
Now, mind you; were this a high-traffic subsystem, where one would
normally have 2 or 3 or 4 requests (changes) outstanding, with a
constant stream coming in keeping the queue full, I'd be out there
screaming for fine-grained locking of individual pieces of it. But
really; how many systems are there (that are using stock passwd and
getpw* and pw/pwd_mkdb/etc) that are adding users at even a significant
fraction of the speed the system can process them? A coarse lock is
easier on the programmer (especially being as we have quickie functions
that do the job for them), the admin (easier to see an extra lock file,
then a hung process holding a flock()), and pretty much everything else.
Why use lockfiles, when we can lock files? Let's lock files and
keep the snack bar open! :-)
We are locking a file :)
We're just locking one file for the whole subsystem, so the pieces can be
assured of being in sync.
So, where's a snack bar with no CVS repository or text editor or diff(1);
I need a vacation!
--
Matthew Fuller (MF4839) | [EMAIL PROTECTED]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
The only reason I'm burning my candle at both ends, is because I
haven't figured out how to light the middle yet
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: bug in pw, -STABLE [patch]
On Sun, Jun 23, 2002 at 05:14:58PM -0700 I heard the voice of Paul Herman, and lo! it spake thus: Clearly, at the root of our disagreement is what we both perceive the problem to be. Oh, certainly; that's what makes it fun :) I don't see problems in the current implementation, aside from bugs that lead to unexpected behavior, i.e. passwd file corruption. You see the problem as a deficiency in the implementation itself, and wish to protect the user from shooting themselves in the foot. Well, we're in violent agreement on the first one. I'm just using that as an opportunity to smack down the second and kill two birds with one stone. Not only do I think that's impossible[*], I choose to fight for my right to shoot myself in the foot as quickly and efficiently as possible, but that's where we'll disagree, and I'll just leave it at that and wish you a good night's sleep. Wouldn't work; the determined foot-screwer would simply cd /etc mv aliases somethingelse ln master.passwd aliases vi aliases. Since we don't have mandatory file locking, it's neither possible nor my intention to prevent people from doing things intentionally; I'm just trying to remove the ways they can do it accidentally using the tools we provide. I'm all for leaving options for people to intentionally de-toe, or convince the system that they know what they're doing while they shoot caterpillars between their toes. Your approach will (I think; I haven't tested, so it's tough to be sure) solve the problem that sparked this, which is that pw(8) has a race condition allowing multiple invocations to step up each other's toes. However, it doesn't do anything about the larger problem of maintaining consistency in the passwd subsystem as a whole, which is where I'm aiming. I also think my approach (once documented, at any rate) would jump out a bit more at people writing programs that adjust the auth information. And, additionally, we took the opportunity to take one MORE step back from the problem, and implement the pid_*() functions which abstract the implementation of this sort of locking, making is easy to apply in other places. Besides, this is a codeocracy; I changed more lines of code than you did, to say nothing of a MANPAGE! My solution MUST be better! 8-} [*] Patch to vi refusing to edit filenames containing master.passwd withheld by request. ;-) rm -f /usr/bin/vi ln -s /usr/local/bin/pico /usr/bin/vi That'll shake people up enough that they won't edit anything. I know it would have ME waking up screaming... -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bug in pw, -STABLE [patch]
On Sun, Jun 23, 2002 at 05:07:40PM -0700 I heard the voice of Terry Lambert, and lo! it spake thus: The problem with your proposed patch is that it breaks the ability to allow authentication against the database while it is undergoing modification, which may be a prolonged period. Would it? For starters, this locks master.passwd, not spwd.db, so any well-behaved program that used getpw*() like a good little monkey wouldn't even notice it. In fact, with Paul's change and the rename() alteration, it'd be BETTER for programs that tried to parse master.passwd, because as it currently stands, there are times when it's incomplete (because of the line-by-line copy, which caused us both a few moments of illness when we noticed it). -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bug in pw, -STABLE [patch]
On Mon, Jun 24, 2002 at 09:56:31AM -0700 I heard the voice of Paul Herman, and lo! it spake thus: On Mon, 24 Jun 2002, Geoffrey C. Speicher wrote: So we either need to have a compelling solution or get a committer to step in and make up our minds for us. I think the best thing to do is file a PR for this. I'll probably do so (referencing also the previous ones) once I finish testing this; the downside is that I may not get a chance to plunk a few straight solid hours into it until this weekend (darn that paying work stuff!), so we may have to find new realms of the subject to flam^Wdebate until then, just to keep the ol' adrenaline flowing. Regardless of the outcome of the passwd issue, I think the pid_*() functions in libutil will be useful for other things that do those kind of functions. Just glancing at my /var/run, I can see cron, inetd, mountd, moused, and syslogd, just among the stuff in our base system that isn't contrib/-ish (like named, sshd, ntpd, etc). -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How does swap work address spacewise?
On Sat, Jul 06, 2002 at 02:37:02PM -0700 I heard the voice of Darren Pilgrim, and lo! it spake thus: And you can have more than a single swap partition. Up to four, so then the theoretical limit for swap is 8TB? I hope not, since I have 6 of 'em. 4's just the default. Do these management structures grow as swap grows, or do they only change as the utilization increases? I believe they're pre-allocated, so it's the size of swap configured (not used) that eats it. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Patch RFC: Promise SATA300 TX4 hardware bug workaround.
On Mon, Nov 19, 2007 at 09:02:33AM +0100 I heard the voice of Søren Schmidt, and lo! it spake thus: I'd like to get the final verdict of the attached patch and if it fixes the problem or not. Behind the curve, as usual, I just upgraded one of my systems that's had the problem in the past to RELENG_7 (which has the fix). It's since moved a bunch of data and done a bunch of builds without a hint of trouble, so looks good to me. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Csup cvsmode build discussion
On Wed, Jan 16, 2008 at 02:32:14PM +0100 I heard the voice of Ulf Lilleengen, and lo! it spake thus: On Wed, Jan 16, 2008 at 11:08:20AM +, Bob Bishop wrote: Why do you want prefixing? Prefixing is needed since csup already have a configuration parser written in lex/yacc and therefore needed to avoid conflicts. Does lex's -P and yacc's -p not rewrite enough? -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: distributed scm+freebsd svn?
On Mon, Jul 27, 2009 at 01:17:34PM +0300 I heard the voice of Andriy Gapon, and lo! it spake thus: P.S. I am looking for a distributed solution (mercurial, bazaar?) that won't take away what I have with git, but would correctly work with svn mergeinfo. I use bazaar, but I don't use the svn integration. AIUI, bzr-svn will _write_ mergeinfo records for merges it creates and pushes into svn, but I don't know whether it reads existing ones. And a great deal of the existing mergeinfo in the BSD repo will be for cherrypicked revs, which aren't recorded anyway, so I don't know how much it would really gain. Vendor branch imports, maybe, but MFC's are right out. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Deprecating ps(1)s -w switch
On Wed, Aug 26, 2009 at 11:40:09PM -0700 I heard the voice of Brian Somers, and lo! it spake thus: I think this is a shame as I find the pros more compelling than the cons, and I'm sure there are more than a few supporters out there on hackers@ that will stay silent. FWIW, I'm in favor of at least carefully examining whether the cons really disqualify the change. My uses of ps pretty well fall into three categories: 1) The times I use -ww 2) The times it doesn't matter whether I did or not 3) The times I wish I'd used -ww, sometimes way later in the game when a script *DOESN'T* do what it's supposed to because ps isn't actually giving me the command. Thanks, ps. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: /etc in CVS
On Thu, Apr 22, 2010 at 04:41:27PM +0200 I heard the voice of Ulrich Spörlein, and lo! it spake thus: I have a .hg directory sitting in / for every machine I usually take care of. hgignore is of course set to *, so only explicitly added files are tracked. I do pretty much the same thing (except mine has .bzr/ and .bzrignore ;). Using the VCS to handle updates requires something a bit broader though. I HAVE considered it. You'd need to do the sort of 'make install' stuff mergemaster does to a tempdir, and make a branch there checking in the snapshots, and have your etc be a derived branch from that. That way you have all the VCS merge capabilities to do the merges and track where they came from. Mergemaster works well enough that I've given no serious thought beyond idle that would be cool thinking on the matter though 8-} -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: fsck and large file system
On Wed, May 12, 1999 at 01:38:00PM -0400, a little birdie told me
that Jim Carroll remarked
I was wondering if anyone has done any work on fsck and very large file
systems. We have a system that has 126 GB RAID Array. As you can imagine,
fsck chokes trying to alloc enough blocks to store it's internal data
structures (128 MB RAM, 128 MB Swap)
Egads. You really want more swap than that, just on GP.
My new workstation (just set the little bugger up today) has 256 megs of
RAM.
[18:13:49] mortis:~
(ttyp1):{1}% pstat -s
Device 1024-blocks UsedAvail Capacity Type
/dev/da0s1b 6552320 655232 0%Interleaved
/dev/da1s1b 5241600 524160 0%Interleaved
/dev/da2s1b 1309440 130944 0%Interleaved
/dev/da3s1b 2620160 262016 0%Interleaved
/dev/da4s1b 5241600 524160 0%Interleaved
Total 20965120 2096512 0%
Now, I'm a bit crazy, so I tend to go overboard. But you'd proabably
want at least 512 megs on a system like that. Hell, you have 126 gig
lying around, you can afford a little more swap ;)
--
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
| Matthew FullerMF4839http://www.over-yonder.net/ |
* fulle...@futuresouth.com fulle...@over-yonder.net *
| UNIX Systems Administrator Specializing in FreeBSD |
* FutureSouth Communications ISPHelp ISP Consulting *
| The only reason I'm burning my candle at both ends, |
*is because I haven't figured out how to light the*
| middle yet |
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: softupdates on root partition, no floppy
On Mon, Jul 19, 1999 at 05:25:06PM +1000, a little birdie told me that Stephen McKay remarked I gave up using soft updates on root because of the delayed delete behaviour. I kept filling up root while updating kernels. It doesn't gain you much on little used file systems anyway. So, I recommend people leave root alone. No, don't leave it alone, make it even SLOWER than usual! /dev/da0s1a on / (local, synchronous, writes: sync 114 async 3850) Question of the day: Why do I have async writes on a sync partition? -- Matthew Fuller (MF4839) |fulle...@over-yonder.net Unix Systems Administrator |fulle...@futuresouth.com Specializing in FreeBSD |http://www.over-yonder.net/ FutureSouth Communications |ISPHelp ISP Consulting The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: softupdates on root partition, no floppy
On Mon, Jul 19, 1999 at 11:25:16PM -0500, a little birdie told me that David Scheidt remarked On Mon, 19 Jul 1999, Matthew D. Fuller wrote: Question of the day: Why do I have async writes on a sync partition? Because only meta-data writes are done synchronously. Data is still done asynchronously. Even with SYNC mounts? (Not 'default', explicit 'sync'. It takes quite noticeable amounts of time to, for instance, install kernels.) From fstab: # DeviceMountpoint FStype Options DumpPass# /dev/da0s1a / ufs rw,sync 1 1 -- Matthew Fuller (MF4839) |fulle...@over-yonder.net Unix Systems Administrator |fulle...@futuresouth.com Specializing in FreeBSD |http://www.over-yonder.net/ FutureSouth Communications |ISPHelp ISP Consulting The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD: the stealth OS?
On Thu, Jul 22, 1999 at 09:51:38AM -0700, a little birdie told me that Matthew Dillon remarked I love the quote by Matthew Fuller at the end: There's a lot of things that Linux is 'better' at, and a lot of things FreeBSD is 'better' at, and a lot of those things can easily fluctuate on a daily or weekly basis, said Fuller, who maintains a Linux vs BSD Web page. Thus, any definitive narrow statement that can be made is usually obsolete before anyone hears it.. Perfect! Thank you, my fans! Please leave your monetary contributions in the hat on your way out; -- Matthew Fuller (MF4839) |fulle...@over-yonder.net Unix Systems Administrator |fulle...@futuresouth.com Specializing in FreeBSD |http://www.over-yonder.net/ FutureSouth Communications |ISPHelp ISP Consulting The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: No MAXUID ?
On Fri, Jul 30, 1999 at 09:13:52AM -0700, a little birdie told me that Mike Smith remarked I think that the administrator should be forced to override the warning manually to indicate that they are aware of the issues they are getting themselves in for, or at the very least that there should be some very serious warnings placed in the relevant manpages (mount_nfs, passwd(5), vipw, etc) covering these issues.a How about a bit of a compromise on it? Make pwd_mkdb just spew a warning like --- WARNING: UID(s) over X detected, may cause problems. --- by default, with a flag (-v?) to list the specific ones causing problems. Warning in manpages are, of course, always a Good Thing. -- Matthew Fuller (MF4839) |fulle...@over-yonder.net Unix Systems Administrator |fulle...@futuresouth.com Specializing in FreeBSD |http://www.over-yonder.net/ FutureSouth Communications |ISPHelp ISP Consulting The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: async v. sync v. default mode on ufs
On Thu, Aug 19, 1999 at 02:15:15PM +0900, a little birdie told me that Daniel C. Sobral remarked Larry Lile wrote: /dev/wd0s1f on /var (asynchronous, local, noatime, synchronous, writes: sync 93 async 216) procfs on /proc (local) /var looks questionable... Indeed. :-) I'm still looking for a 'splanation for this one: /dev/da0s1a on / (local, synchronous, writes: sync 34 async 954) ^^^ ^ I don't WANT async writes! -- Matthew Fuller (MF4839) |fulle...@over-yonder.net Unix Systems Administrator |fulle...@futuresouth.com Specializing in FreeBSD |http://www.over-yonder.net/ FutureSouth Communications |ISPHelp ISP Consulting The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Async NFS exports?
[ Caveat: I'm making this up as I go along ] On Fri, Aug 20, 1999 at 01:13:06PM -0500, a little birdie told me that Steve Ames remarked I asked this on stable but didn't get a response... Would I get any performance increases by mounting NFS exported partition as Async? Would my soul be tormented in purgatory for doing it? Just to be clear... I am wondering if mounting (on the NFS _server_) a partition (that is exportable) as async will have any performance benefits to the NFS clients? As a first guess, probably not unless you have a large number of active clients. Any modern hard disc will outperform ethernet/fast ethernet, especially for larger read/writes. For large numbers of smaller operations, or when there is a large number of simultaneous outstanding requests from clients, maybe. I'd say watch the disc itself (iostat is your friend), and if it's pegged (especially large numbers of tps) async might buy you some increase. -- Matthew Fuller (MF4839) |fulle...@over-yonder.net Unix Systems Administrator |fulle...@futuresouth.com Specializing in FreeBSD |http://www.over-yonder.net/ FutureSouth Communications |ISPHelp ISP Consulting The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Init(8) cannot decrease securelevel
On Mon, Sep 06, 1999 at 08:39:54AM -0700, a little birdie told me that Matthew Dillon remarked Though, as a side note, it should be noted that if you have DDB enabled then lowering the secure level is pretty easy to do. If you have access to the console, of course. We used this trick at BEST a couple of times. Still, I think this might qualify as a bug in the securelevel implementation. I don't know about 'bug in securelevel implementation'... For DDB to be DDB, you have to be able to tweak the running kernel any which way outside of its control. For securelevel to be securelevel, you have to prevent changes to X, Y, and Z, no matter how they're changed. I think it's more of a 'DDB is antithecal to securelevel'. Calling it a bug in securelevel is like calling lack of cargo space a bug in a Geo Metro. -- Matthew Fuller (MF4839) |fulle...@over-yonder.net Unix Systems Administrator |fulle...@futuresouth.com Specializing in FreeBSD |http://www.over-yonder.net/ FutureSouth Communications |ISPHelp ISP Consulting The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Phenom II 975 BE shows 0 celsius
On Sun, Jul 31, 2011 at 09:28:29PM -0300 I heard the voice of Mario Lobo, and lo! it spake thus: Unfortunately this Mobo died and only found AM3 boards for which my phenom 955 doesn't fit. Not that it helps you now, but the 955 _is_ perfectly compatible with AM3. It's only the initial 920 and 940 that were AM2-only. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, Jan 17, 2012 at 02:50:08PM -0600 I heard the voice of Mark Felder, and lo! it spake thus: I've seen several other things hit -STABLE right after the freeze ended early January which surprise me that they weren't included in -RELEASE and we didn't have another RC. You mean the 9.0-RELEASE that's scheduled to be done (after having already slipped a month) at the beginning of Sept 2011? At some point (well before those add'l patches you're talking about, IMO) you have to STOP and release the damn thing already. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, Jan 17, 2012 at 12:02:29PM + I heard the voice of Tom Evans, and lo! it spake thus: You say that snapshots of STABLE are stable and effectively a running release branch, so why can't more releases be made? Is the release process too complex for minor revisions, could that be improved to make it easier to have more releases, eg by not bundling ports packages? That's at LEAST a double edged sword. The moment you do that, you'll have a giant groundswell of complaining about how the quality of releases has gone down. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, Jan 17, 2012 at 06:57:19PM + I heard the voice of Hugo Silva, and lo! it spake thus: Come to think about it, those days are pretty much gone since 4.x (incidentally, many of us who've stuck with FreeBSD for this long think of 4.x as an epic series). Having been a FreeBSD user for a very long time, I don't think of 4.x as epic. I think of 5.x as a clusterf...un. 4.x didn't last such a long time because everyone thought it was awesome, it was because the next version was still so broken it was the only thing we had to release. And the reason it developed whatever excess stability it may have had is _because_ it was moribund. It's trivial to avoid introducing new bugs to software; all you have to do is never change it. The next best thing is to make very small targetted changes with enormous care to make them local. But that means you DON'T get things like new drivers and infrastructure and so on, because those are just the sort of big changes that are likely to create new problems even as they solve existing ones. At some point aroudn X.4 or X.5 it stops being -STABLE and starts just being -STALE. For me, the smaller jumps between major releases are a *GOOD* thing, because it makes it parsecs easier to move between them. Moving a system from 4 to 5 was a giant nightmare of everything breaking. The only thing I can remember worse was moving from 2.2 to 3 (and actually, most of my 2.2 systems either stayed that way until they died, or got moved via *HEROIC* efforts straight to 4). In contrast, moving from 6-7-8 was only a slightly larger bump than moving from 6.X to 6.Y. I have a specific system that I'm holding back moving from 8 to 9 now because of a specific change, and I'm sorta hoping I can retire that system before I have to try it. If we went back to the days of mega-major's, that would happen *EVERY* time. Now, there are some environments where upgrades are rare major events and every single upgrade (possibly excluding those that can be honestly described as single targetted patch) requires a giant pile of from-scratch requalification. And in those cases, it's almost the same amount of work whether you're going from 4.6-4.7 as if you were doing 4.10-9.1. From that perspective, sure, giant lengthenings may sound like an excellent idea. But from the position of considering upgrades as common and minor things, giant leaps are a nightmare I want to avoid at all costs. Maybe I'm horribly mistaken about the releasographics of production FreeBSD users, but I think most of us tend to run -release [...] I doubt it would be easy to get stats. But you could probably draw a reasonable correlation between people using releases and binary packages, vs. source and port builds. That would probably be easier to get numbers on. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Wed, Jan 18, 2012 at 01:41:53AM + I heard the voice of Igor Mozolevsky, and lo! it spake thus: The problem, however, lies in the time between a patch is submitted and is picked up, if the latter ever occurs!.. That is where the discouragement occurs. Quite. For instance, we're now well past the 3 year mark since I submitted docs/127908, which fixes 1 sentence in a manpage. So far, I can't see that anybody but me has ever looked at it. That doesn't serve to encourage me to nibble at anything substantial. (In fairness, I should note that I also maintain several ports, and so submit a steady trickle of PR's there. Almost none of them take more than a week from submission to application and closing, and it's fairly common for it to be less than 24 hours. I know the ports team carries a huge load with such things, but they're carrying it well.) -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, Jan 17, 2012 at 06:49:02PM -0800 I heard the voice of Julian Elischer, and lo! it spake thus: 5 was not out on a limb for so long because it was a clusterfun, it was out there because it was a rework of how almost everything in the kernel worked. I'm not saying it was a cluster because it was a huge amount of very deep work; it's because that huge amount of very deep work completely gated our next release. Now, sure, changing external circumstances caught us with our pants down, and the tools we were using (like CVS) made it hard to do anything else. But that just means there were good reasons why it happened; doesn't make it less clusterfull :) The two circumstances (giant rework, and long period between major releases) are duals of each other. If we chop off giant piles of stuff to do for FreeBSD-next, it's going to take a very long time. And if we instead just set very long times (Jan 2017 for 10?! Insanity!) for -next, we're going to end up with giant reworks and huge differences. And _both_ faces are very bad. The one means we wait forever for any new work, and the other means that it takes enormous amounts of work as a user to transistion across the barrier. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: * Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, Jan 17, 2012 at 07:20:15PM -0800 I heard the voice of Julian Elischer, and lo! it spake thus: the trouble with 5 was that it had to be all-or-nothing. [...] the size of the giant pile of stuff was not of our choosing. As may be, it's beside my point. Whether due to malice, incompetence, or the unalterable ways of the universe, 5 spent something approaching forever not ready to release, and depending on who you ask, kept that status until it became known as 6.0. And that, not 4 is awesome, is the principal reason 4 kept chugging so long. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Wed, Jan 18, 2012 at 02:20:56PM -0600 I heard the voice of Mark Felder, and lo! it spake thus: On Wed, 18 Jan 2012 13:46:45 -0600, John Kozubik j...@kozubik.com wrote: This is nice because no upheaval needs to happen with 7 and 8, and interested developers do not get kneecapped vis a vis 9 - they can just keep going where they were going with it, and the only real change is that 10 is pushed out a long ways, and people[1] get to really sink their teeth into 9. What are the policies for changes though? Are we stuck with 9.0's feature set for 5 years? Will we have to wait 5 years to get a stable release of FreeBSD with KMS/GEM? That work is unfinished and didn't make 9.0; it's also a huge changeset. How will things like this be dealt with? Five years is a long time for the next stable release if we have a policy to not import major changes from -CURRENT. It would be devastating to so many users. This is where the problem comes in. As I read it, John's problem in a sentence is I just got onto 8.x, and it's already shutting down! If the problem is stable trains don't live long enough, why, the solution's simple; make stable trains live longer! The problem is, there are unpleasant tradeoffs every direction we try to go with that. We can: 1) Just make each one live longer. Of course, that means that pretty soon we're maintaining 3 and 4 -STABLE branches all the time. Yeah... maintaining is sure to be an overstatement in that case. Even if we had massively more manpower, the project management complexity would still eat us alive. This is just a non-starter. 2) Wait longer between making new ones. This is what John is suggesting above, but it has two related huge drawbacks. The a) As Mark said, is that it means any significant new features or architectures come out a couple years after they're already obsolete. To pick one example, from 8-9 we have the new eventtimers stuff, which drastically reduces the number of clock interrupts. As we get 4 and 8 and 16 and higher core counts becoming common, that gets very important, as servicing 32k interrupts/second while completely idle is really bad for system efficiency. If we pushed 9 out to 2 years or so from now, we're telling people sure, just eat the overhead until then. Whoops. b) The other big drawback is as I've said in other mails; it turns every major release into a giant watershed of everything changing, which makes upgrading systems across it a *HUGE* amount of work, and *VERY* risky. Again, this had an impact in the 4/5 days; upgrading to 5 was so risky and so different, that lots of people stayed on 4 long after it was out. I sure don't want to deal with that sort of divide again. The more frequent major release steps are, the smaller and easier they are. Now, you could say Well, 2(a) just won't be a problem because we'll merge more stuff back. But now all you're doing is making that -STABLE branch _less_ stable, compromising the reason people are using it in the first place. Now, sure, 'stable' isn't a binary condition, and we can always re-evaluate just where we want to stick the needle. Maybe we could be a bit more aggressive about the size of changes we merge back. But I don't believe that we could get _near_ enough backporting to alleviate the time between the big/dangerous new feature landings, without seriously compromising the stability of -STABLE. Or there's another option, a variant of (1), where we extend the lifetime of some major release trains, but not all. Every second, or every third. Then we can have a longer life, without ballooning out the number of trains being supported. But that has big drawbacks too; the problems of backporting aren't just the number of branches to port too, but how far back they are. Backporting from -CURRENT to 9 right now is almost trivial. Going to 8 isn't too bad for most things. To 7, it's getting to be a much bigger deal. If 7 were an extended support train, with 2 years of active support left on it, not only would backporting things get inordinately expensive from accumulated differences, but they'd get very _risky_ too. They slip from backport into rewrite for, and now we've seriously compromised the stability of the branch, undermining our own goals. Now, I don't suggest the current state is perfect. There are certainly relatively minor tweaks like more common minor releases that could improve things in some quarters. And they're local enough that they can conceptually be done without rippling out and messing with everything else in the project. But trying to do major shifts aren't as simple as just make major releases less often; the tweaks you can do like that all have _very_ seriously side effects, make a lot of things much worse, and would require a lot of _very_ careful rebalancing of everything else to avoid a significant overall lose. -- Matthew
