Re: long pause in startup
I don't know anything about your problem, but does it give good info if you boot with verbose on? Ronald. On Wed, 18 Jul 2007 03:08:29 +0200, Charles Sprickman [EMAIL PROTECTED] wrote: Hi all, Any ideas on this one? This machine (one of those ancient VALinux 2U boxes, Intel L440GX+ board, dual PIII) hangs for a very long time between the second processor launching and geom_mirror kicking in. It does always boot, but the hang is more than a minute - just enough to make one nervous when rebooting remotely... Is this just the mirror taking a really long time to initialize, or something more sinister? Here's part of the dmesg with an indication of where it hangs: Waiting 5 seconds for SCSI devices to settle da0 at ahc0 bus 0 target 0 lun 0 da0: SEAGATE ST173404LWV 4301 Fixed Direct Access SCSI-3 device da0: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) da1 at ahc0 bus 0 target 1 lun 0 da1: SEAGATE ST173404LWV 4301 Fixed Direct Access SCSI-3 device da1: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled da1: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) SMP: AP CPU #1 Launched! -- 1 minute+ -- GEOM_MIRROR: Device gm0 created (id=3517779574). GEOM_MIRROR: Device gm0: provider da0 detected. GEOM_MIRROR: Device gm0: provider da1 detected. GEOM_MIRROR: Device gm0: provider da1 activated. GEOM_MIRROR: Device gm0: provider da0 activated. GEOM_MIRROR: Device gm0: provider mirror/gm0 launched. Trying to mount root from ufs:/dev/mirror/gm0s1a Any info is appreciated, this is just something I wanted to check out before bringing this into production (secondary ns, mx w/pfspamd). Thanks! Charles ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Ronald Klop Amsterdam, The Netherlands ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
removing external usb hdd without unmounting causes reboot?
Hi, I am running FreeBSD 6.2-STABLE #11: Sat Jul 14 16:27:12 CEST 2007 and accidently unplugged the USB hub to which my external hdd together with a mouse were connected and this caused my machine to freeze for some seconds and then reboot. At that moment the hdd was mounted and I was playing music out of it. After that I tried to reproduce it :) so just plugged only the hdd directly, mounted it and started playing music files from it. When I unplugged the USB cable the same thing happened: short freeze, and then reboot. Is this expected behaviour? And is there some way to avoid the freeze and reboot? Thanks. -- PGP KeyID: 0x3118168B Keyserver: pgp.mit.edu Key fingerprint BB50 2983 0714 36DC D02E 158A E03D 56DA 3118 168B ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell PERC5/i SAS5/5IR - RAID monitoring
Michael Worobcuk wrote: Am 18.07.2007 um 01:27 schrieb Tom Judge: Michael Worobcuk wrote: Hi, I am trying to set up my first webserver. I bought a Dell Poweredge 860, provided with a SAS5/IR RAID-Controller. The problem is now, that I cannot find software, that monitors the state of my disks. I already tried megarc from the ports but all I get is a short answer that no adapters where found: # megarc -AllAdpInfo -nolog ** MEGARC MegaRAID Configuration Utility(FreeBSD)-1.04(03-02-2005) By LSI Logic Corp.,USA ** [Note: For SATA-2, 4 and 6 channel controllers, please specify Ch=0 Id=0..15 for specifying physical drive(Ch=channel, Id=Target)] Type ? as command line arg for help No Adapters Found Error: No MegaRaid Found # I had emails with Dell and LSI. Dell does not support FreeBSD and LSI says I should go and ask Dell ... The second thing is, the perfomance. SNIP Final score for writes:16 Final score for reads : 2025 # (Just to remember: Pentium D; 2,8GHZ; 4 GB RAM; 2 x 500GB SATA RAID1) That is pretty poor, isn't it ? I am wondering now, if somebody has experience with the PERC5/I Controller. Would it be possible to monitor the disks, if I would buy that controller ? Any hints are highly appreciated. Thanks Michael I don't know about monitoring the SAS5/I however I read some posts on one of the lists that was talking about the linux compatibility system providing all of the correct interface for the linux version of ?megacli? to work on FreeBSD. As the SAS5/I is mpt driver based could it not be checked with camcontrol? (Just an idea never tested). SNIP Hi Tom, thank you for your response. What about monitoring the PERC5/ie ? Does it work with megarc or any program under FreeBSD ? Just to clarify that the the following was related to the PERC5/ie and the mfi driver: I read some posts on one of the lists that was talking about the linux compatibility system providing all of the correct interface for the linux version of megacli/megarc to work on FreeBSD I think google can answer the rest for you. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mysqld got signal 11
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ken Chen wrote: db1# cat /boot/loader.conf kern.maxdsiz=2G kern.dfldsiz=2G kern.maxssiz=134217728 # 128MB I don't think the boot loader understands 2G to mean two gigabytes (unlike my.cnf). It has probably left you with the default values. Try spelling it out as so: kern.maxdsiz=2147483648 kern.dftdsiz=2147483648 Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGnekV8Mjk52CukIwRCG7tAJ0SDevjout/RNDl0UJyak9sCzcoxQCfZjmE 7sRY1dmudyAMeHgrtEDKElU= =4TZ8 -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: long pause in startup
Charles Sprickman wrote: Any ideas on this one? This machine (one of those ancient VALinux 2U boxes, Intel L440GX+ board, dual PIII) hangs for a very long time between the second processor launching and geom_mirror kicking in. It does always boot, but the hang is more than a minute - just enough to make one nervous when rebooting remotely... Is this just the mirror taking a really long time to initialize, or something more sinister? [snip] Any info is appreciated, this is just something I wanted to check out before bringing this into production (secondary ns, mx w/pfspamd). I've got a bunch of these and they all do it. It seems to be something with the floppy controller. During the hang it's accessing the floppy drive (light is on) and if the floppy is disabled, there is no hang. IIRC if you have a floppy in the drive it also does not hang. That's the short version, anyhow. It's been discussed on the list before so you might check the archives for a better/more complete answer. Jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removing external usb hdd without unmounting causes reboot?
On Wed, Jul 18, 2007 at 11:42:26AM +0200, Momchil Ivanov wrote: accidently unplugged the USB hub to which my external hdd together with a mouse were connected and this caused my machine to freeze for some seconds and then reboot. Yes, this is a known problem, for which there is no workaround at the moment. mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removing external usb hdd without unmounting causes reboot?
On Wednesday 18 July 2007, Momchil Ivanov wrote: Hi, I am running FreeBSD 6.2-STABLE #11: Sat Jul 14 16:27:12 CEST 2007 and accidently unplugged the USB hub to which my external hdd together with a mouse were connected and this caused my machine to freeze for some seconds and then reboot. At that moment the hdd was mounted and I was playing music out of it. After that I tried to reproduce it :) so just plugged only the hdd directly, mounted it and started playing music files from it. When I unplugged the USB cable the same thing happened: short freeze, and then reboot. Is this expected behaviour? And is there some way to avoid the freeze and reboot? Thanks. Yes, it's expected behavior. The workaround is to not unplug mounted devices. (There's nothing special about USB here, if you unplugged an IDE drive you'd get the same behavior) -- Thanks, Josh Paetzel pgpUBWpa2fyAG.pgp Description: PGP signature
Re: removing external usb hdd without unmounting causes reboot?
Josh Paetzel wrote: On Wednesday 18 July 2007, Momchil Ivanov wrote: Hi, I am running FreeBSD 6.2-STABLE #11: Sat Jul 14 16:27:12 CEST 2007 and accidently unplugged the USB hub to which my external hdd together with a mouse were connected and this caused my machine to freeze for some seconds and then reboot. At that moment the hdd was mounted and I was playing music out of it. After that I tried to reproduce it :) so just plugged only the hdd directly, mounted it and started playing music files from it. When I unplugged the USB cable the same thing happened: short freeze, and then reboot. Is this expected behaviour? And is there some way to avoid the freeze and reboot? Thanks. Yes, it's expected behavior. The workaround is to not unplug mounted devices. (There's nothing special about USB here, if you unplugged an IDE drive you'd get the same behavior) Wouldn't it make some sense not to panic if mounted devices that are in sync get removed? A few applications might get in trouble, but that's hardly a reason to bring a whole system down. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell PERC5/i SAS5/5IR - RAID monitoring
Hi Tom, thank you for your response. What about monitoring the PERC5/ie ? Does it work with megarc or any program under FreeBSD ? I have some scripts on nagiosexchange.org; wrappers around megacli(8) and megarc(8). ~BAS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] l8* -lava (Brian A. Seklecki - Pittsburgh, PA, USA) http://www.spiritual-machines.org/ Guilty? Yeah. But he knows it. I mean, you're guilty. You just don't know it. So who's really in jail? ~Maynard James Keenan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removing external usb hdd without unmounting causes reboot?
On Wednesday 18 July 2007 15:52:42 [LoN]Kamikaze wrote: Josh Paetzel wrote: On Wednesday 18 July 2007, Momchil Ivanov wrote: Hi, I am running FreeBSD 6.2-STABLE #11: Sat Jul 14 16:27:12 CEST 2007 and accidently unplugged the USB hub to which my external hdd together with a mouse were connected and this caused my machine to freeze for some seconds and then reboot. At that moment the hdd was mounted and I was playing music out of it. After that I tried to reproduce it :) so just plugged only the hdd directly, mounted it and started playing music files from it. When I unplugged the USB cable the same thing happened: short freeze, and then reboot. Is this expected behaviour? And is there some way to avoid the freeze and reboot? Thanks. Yes, it's expected behavior. The workaround is to not unplug mounted devices. (There's nothing special about USB here, if you unplugged an IDE drive you'd get the same behavior) Wouldn't it make some sense not to panic if mounted devices that are in sync get removed? A few applications might get in trouble, but that's hardly a reason to bring a whole system down. I don`t know how things work, but shutting down the system when some mounted fs is no longer present seems like the wrong thing to me. It`s surely safe :) just bring everything down in order to ensure not messing things ups. But nowadays there are a lot of USB devices and umounting every time is something that one is surely going to forget once and ooops everyting goes down. If the same thing happens when a network fs is mounted (say NFS or SMBFS) and then becomes unavailable due to network outages (wireless connections break easily compared to cable connections, and nowadays the former become popular), then I think it should be fixed. Windows doesn`t reboot if you unplug the usb or network cable, which I think is the right way of handling these kind of situations. Idea: do something like umount -f when a fs becomes unavailabe, just tell every program that files are unaccessible? I don`t have the programming skills and knowledge of how freebsd works, that`s why I can only help with feedback and ideas :) Shutting down the system without user`s desire seems like a problem to me, regardless of the reason. And problems are there to be solved. -- PGP KeyID: 0x3118168B Keyserver: pgp.mit.edu Key fingerprint BB50 2983 0714 36DC D02E 158A E03D 56DA 3118 168B pgpIlHaW3FprO.pgp Description: PGP signature
Properly managing SpamAssassin. . .
Hi All, I'm looking for a way to properly manage SpamAssassin after Plesk has wreaked havoc on the server. In the short term, we need to keep Plesk around for those that need the ease of use. However, it wants to keep resetting values, etc; meaning that since the Plesk license doesn't support SpamAssassin it won't allow us to use it and wants it to remain that way. If push comes to shove, I *will* blast Plesk. That said, I need to figure out the proper way to enable SpamAssassin and have Qscan work properly, circumventing the Plesk activites and licensing limitations. Does anyone have any quality insight into the most up-to-date means for accomplishing this? Regards, Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removing external usb hdd without unmounting causes reboot?
I vaguely remember being able to yank out USB drives in 5.x and just make usbd execute a forced umount without any problems. FAT32 drives mind you. On 6.2 I haven't even been able to unplug a USB drive even if I unmount it first, always results in a kernel panic. Baldur On Wed, Jul 18, 2007 at 08:39:46AM -0500, Josh Paetzel wrote: On Wednesday 18 July 2007, Momchil Ivanov wrote: Hi, I am running FreeBSD 6.2-STABLE #11: Sat Jul 14 16:27:12 CEST 2007 and accidently unplugged the USB hub to which my external hdd together with a mouse were connected and this caused my machine to freeze for some seconds and then reboot. At that moment the hdd was mounted and I was playing music out of it. After that I tried to reproduce it :) so just plugged only the hdd directly, mounted it and started playing music files from it. When I unplugged the USB cable the same thing happened: short freeze, and then reboot. Is this expected behaviour? And is there some way to avoid the freeze and reboot? Thanks. Yes, it's expected behavior. The workaround is to not unplug mounted devices. (There's nothing special about USB here, if you unplugged an IDE drive you'd get the same behavior) -- Thanks, Josh Paetzel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Properly managing SpamAssassin. . .
Thanks, but there are two issues there: 1) I don't plan on keeping Plesk for more than a few months, and don't want to spend the effort/money just to undo/redo it later. 2) I want to manage it manually 100% from the start That said, are there any suggestions as to how to accomplish what I've requested? Regards, Michael On Jul 18, 2007, at 11:28 AM, Daniel Anson wrote: You can buy a spamassasin liscense from plesk. I would suggest that. Daniel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Williams Sent: Wednesday, July 18, 2007 10:05 AM To: freebsd-stable@freebsd.org Subject: Properly managing SpamAssassin. . . Hi All, I'm looking for a way to properly manage SpamAssassin after Plesk has wreaked havoc on the server. In the short term, we need to keep Plesk around for those that need the ease of use. However, it wants to keep resetting values, etc; meaning that since the Plesk license doesn't support SpamAssassin it won't allow us to use it and wants it to remain that way. If push comes to shove, I *will* blast Plesk. That said, I need to figure out the proper way to enable SpamAssassin and have Qscan work properly, circumventing the Plesk activites and licensing limitations. Does anyone have any quality insight into the most up-to-date means for accomplishing this? Regards, Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Properly managing SpamAssassin. . .
Kevin, Thanks. I have no problem with that at all. Can you recommend any quality, modular (redundant I know) jailing techniques (e.g. directory structures, user levels, permissions, etc)? Regards, Michael On Jul 18, 2007, at 11:34 AM, Kevin K. wrote: Managing plesk usually means that you really have to hand over your server (or the jail that plesk creates) to plesk itself. I've hacked and mangled plesk installations in order to merge other technologies and custom solutions that I personally preferred -- and in the end I concluded that it caused more headaches than it was worth. As of plesk 8.1 I believe it creates its installation in a jailed environment, so perhaps adding another jail to handle all the services you don't want to purchase through plesk (i.e. spamassassin, clamav, or whatever elese there is) may be the best way. That's my 0.2, perhaps someone else has a better solution though. Again, changing or hacking a plesk installation is not a good idea, considering their windows update style of submitting upgrades and patches. Hope it helps. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Williams Sent: Wednesday, July 18, 2007 11:05 AM To: freebsd-stable@freebsd.org Subject: Properly managing SpamAssassin. . . Hi All, I'm looking for a way to properly manage SpamAssassin after Plesk has wreaked havoc on the server. In the short term, we need to keep Plesk around for those that need the ease of use. However, it wants to keep resetting values, etc; meaning that since the Plesk license doesn't support SpamAssassin it won't allow us to use it and wants it to remain that way. If push comes to shove, I *will* blast Plesk. That said, I need to figure out the proper way to enable SpamAssassin and have Qscan work properly, circumventing the Plesk activites and licensing limitations. Does anyone have any quality insight into the most up-to-date means for accomplishing this? Regards, Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable- [EMAIL PROTECTED] __ NOD32 2404 (20070717) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Properly managing SpamAssassin. . .
You can buy a spamassasin liscense from plesk. I would suggest that. Daniel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Williams Sent: Wednesday, July 18, 2007 10:05 AM To: freebsd-stable@freebsd.org Subject: Properly managing SpamAssassin. . . Hi All, I'm looking for a way to properly manage SpamAssassin after Plesk has wreaked havoc on the server. In the short term, we need to keep Plesk around for those that need the ease of use. However, it wants to keep resetting values, etc; meaning that since the Plesk license doesn't support SpamAssassin it won't allow us to use it and wants it to remain that way. If push comes to shove, I *will* blast Plesk. That said, I need to figure out the proper way to enable SpamAssassin and have Qscan work properly, circumventing the Plesk activites and licensing limitations. Does anyone have any quality insight into the most up-to-date means for accomplishing this? Regards, Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removing external usb hdd without unmounting causes reboot?
Momchil Ivanov wrote: On Wednesday 18 July 2007 15:52:42 [LoN]Kamikaze wrote: Josh Paetzel wrote: Yes, it's expected behavior. The workaround is to not unplug mounted devices. (There's nothing special about USB here, if you unplugged an IDE drive you'd get the same behavior) Wouldn't it make some sense not to panic if mounted devices that are in sync get removed? A few applications might get in trouble, but that's hardly a reason to bring a whole system down. I don`t know how things work, but shutting down the system when some mounted fs is no longer present seems like the wrong thing to me. As Josh wrote, it's expected. The problem is known to exist for a long time already (probably as long as FreeBSD itself exists), and if there was an easy solution, certainly someone would have fixed it. Just remember to always umount first, and you're safe. In the early 90s I panicked a FreeBSD machine by removing a floppy disk that was mounted. I did that mistake only once -- afterwards I always remembered. If you have problems remembering, another work-around is to use the auto mounter daemon (amd(8)). It umounts file systems automatically that are not in use. Another nice feature of amd(8) is that you don't have to mount the file system either -- Simply plug the USB stick in, then access it, and amd(8) will automatically mount it for you. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd I learned Java 3 years before Python. It was my language of choice. It took me two weekends with Python before I was more productive with it than with Java. -- Anthony Roberts ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removing external usb hdd without unmounting causes reboot?
On Wed, Jul 18, 2007 at 05:03:03PM +0200, Momchil Ivanov wrote: Windows doesn`t reboot if you unplug the usb or network cable, which I think is the right way of handling these kind of situations. Windows also (as of XP; I don't think it was this way in 2000) by default disables read/write caching on all USB-plugged storage devices. This was done because people were unplugging USB storage devices without shutting them down (going to the systray and selecting the device then choosing Stop to ensure all caches were flushed and data on the device had been written). The performance hit is pretty major, but the attitude is safety first. You can, of course, toggle the caching feature per device/drive, but you'll need to Stop the device before removing it from the USB bus. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Properly managing SpamAssassin. . .
Managing plesk usually means that you really have to hand over your server (or the jail that plesk creates) to plesk itself. I've hacked and mangled plesk installations in order to merge other technologies and custom solutions that I personally preferred -- and in the end I concluded that it caused more headaches than it was worth. As of plesk 8.1 I believe it creates its installation in a jailed environment, so perhaps adding another jail to handle all the services you don't want to purchase through plesk (i.e. spamassassin, clamav, or whatever elese there is) may be the best way. That's my 0.2, perhaps someone else has a better solution though. Again, changing or hacking a plesk installation is not a good idea, considering their windows update style of submitting upgrades and patches. Hope it helps. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Williams Sent: Wednesday, July 18, 2007 11:05 AM To: freebsd-stable@freebsd.org Subject: Properly managing SpamAssassin. . . Hi All, I'm looking for a way to properly manage SpamAssassin after Plesk has wreaked havoc on the server. In the short term, we need to keep Plesk around for those that need the ease of use. However, it wants to keep resetting values, etc; meaning that since the Plesk license doesn't support SpamAssassin it won't allow us to use it and wants it to remain that way. If push comes to shove, I *will* blast Plesk. That said, I need to figure out the proper way to enable SpamAssassin and have Qscan work properly, circumventing the Plesk activites and licensing limitations. Does anyone have any quality insight into the most up-to-date means for accomplishing this? Regards, Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] __ NOD32 2404 (20070717) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Properly managing SpamAssassin. . .
Creating a jail isn't that hard. Unfortunately I haven't really tested it before, but im sure that through some simple redirection of the separate virtual localhost adapters between jails, you may be able to utilize spamassassin. I guess the real question is, is it worth it to do all that work if you are going to just scrap plesk in a few months anyways? In any case, the freebsd handbook's section on jails is a good place to start. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Williams Sent: Wednesday, July 18, 2007 11:39 AM To: Kevin K. Cc: freebsd-stable@freebsd.org Subject: Re: Properly managing SpamAssassin. . . Kevin, Thanks. I have no problem with that at all. Can you recommend any quality, modular (redundant I know) jailing techniques (e.g. directory structures, user levels, permissions, etc)? Regards, Michael On Jul 18, 2007, at 11:34 AM, Kevin K. wrote: Managing plesk usually means that you really have to hand over your server (or the jail that plesk creates) to plesk itself. I've hacked and mangled plesk installations in order to merge other technologies and custom solutions that I personally preferred -- and in the end I concluded that it caused more headaches than it was worth. As of plesk 8.1 I believe it creates its installation in a jailed environment, so perhaps adding another jail to handle all the services you don't want to purchase through plesk (i.e. spamassassin, clamav, or whatever elese there is) may be the best way. That's my 0.2, perhaps someone else has a better solution though. Again, changing or hacking a plesk installation is not a good idea, considering their windows update style of submitting upgrades and patches. Hope it helps. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Williams Sent: Wednesday, July 18, 2007 11:05 AM To: freebsd-stable@freebsd.org Subject: Properly managing SpamAssassin. . . Hi All, I'm looking for a way to properly manage SpamAssassin after Plesk has wreaked havoc on the server. In the short term, we need to keep Plesk around for those that need the ease of use. However, it wants to keep resetting values, etc; meaning that since the Plesk license doesn't support SpamAssassin it won't allow us to use it and wants it to remain that way. If push comes to shove, I *will* blast Plesk. That said, I need to figure out the proper way to enable SpamAssassin and have Qscan work properly, circumventing the Plesk activites and licensing limitations. Does anyone have any quality insight into the most up-to-date means for accomplishing this? Regards, Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable- [EMAIL PROTECTED] __ NOD32 2404 (20070717) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] __ NOD32 2404 (20070717) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removing external usb hdd without unmounting causes reboot?
On Wednesday 18 July 2007 17:41:04 Oliver Fromme wrote: As Josh wrote, it's expected. The problem is known to exist for a long time already (probably as long as FreeBSD itself exists), and if there was an easy solution, certainly someone would have fixed it. Just remember to always umount first, and you're safe. In the early 90s I panicked a FreeBSD machine by removing a floppy disk that was mounted. I did that mistake only once -- afterwards I always remembered. If you have problems remembering, another work-around is to use the auto mounter daemon (amd(8)). It umounts file systems automatically that are not in use. Another nice feature of amd(8) is that you don't have to mount the file system either -- Simply plug the USB stick in, then access it, and amd(8) will automatically mount it for you. Best regards Oliver I started the thread just because it hit me today. I wanted to disconnect my mouse and forgot that the hdd is connected to the same hub, I realized that after having unplugged the usb hub and saw the system freeze. I know that this has been an issue for a long time. With cdroms it`s easy, the tray won`t open until you umount the cd fs, floppies. nowadays they have been replaced by usb sticks, but they have no trays as cdroms do :) moreover people use other usb storages too and unplugging those is just as simple as unpluging the cable. I think this is a critical problem and needs to be addressed, avoiding it doesn`t solve it. As technology advances I think FreeBSD has to advance too. You said you paniced a system in the early 90s, which is more than 10 years from now. In the past floppy disks were maybe the only problem, but nowadays as storage is cheap more and more people use USB storage devices, and these are easy to unplug. It`s even worse if you have a laptop, since it`s easier to connect everything to a hub (mouse, hdds, other usb stuff) and connect/disconnect it. In the days before common storage devices (hard drives) where fixed inside the computer`s case, so unpluging a hard drive when the computer was running was considered as insane, so panicing is ok. Nowadays things have changed. USB (maybe Firewire too, have no experience with that) offers a simple way to connect/disconnect devices to your computer (here I have to note: not just one!), having a laptop and 1,2,3 or even more external storage devices is something usual. That`s why I think this particular problem needs to be addressed. Thanks for the tip about amd(8) I will give it a try. -- PGP KeyID: 0x3118168B Keyserver: pgp.mit.edu Key fingerprint BB50 2983 0714 36DC D02E 158A E03D 56DA 3118 168B pgpPIKc8k2BdR.pgp Description: PGP signature
Re: removing external usb hdd without unmounting causes reboot?
This really struck me as a problem when I had a short power outage and my external USB hard drive wasn't plugged into the UPS. Laptop didn't reboot from the power outage but it rebooted anyway because it lost a hard drive (which was mounted but I wasn't doing any work on) Baldur On Wed, Jul 18, 2007 at 06:30:44PM +0200, Momchil Ivanov wrote: On Wednesday 18 July 2007 17:41:04 Oliver Fromme wrote: As Josh wrote, it's expected. The problem is known to exist for a long time already (probably as long as FreeBSD itself exists), and if there was an easy solution, certainly someone would have fixed it. Just remember to always umount first, and you're safe. In the early 90s I panicked a FreeBSD machine by removing a floppy disk that was mounted. I did that mistake only once -- afterwards I always remembered. If you have problems remembering, another work-around is to use the auto mounter daemon (amd(8)). It umounts file systems automatically that are not in use. Another nice feature of amd(8) is that you don't have to mount the file system either -- Simply plug the USB stick in, then access it, and amd(8) will automatically mount it for you. Best regards Oliver I started the thread just because it hit me today. I wanted to disconnect my mouse and forgot that the hdd is connected to the same hub, I realized that after having unplugged the usb hub and saw the system freeze. I know that this has been an issue for a long time. With cdroms it`s easy, the tray won`t open until you umount the cd fs, floppies. nowadays they have been replaced by usb sticks, but they have no trays as cdroms do :) moreover people use other usb storages too and unplugging those is just as simple as unpluging the cable. I think this is a critical problem and needs to be addressed, avoiding it doesn`t solve it. As technology advances I think FreeBSD has to advance too. You said you paniced a system in the early 90s, which is more than 10 years from now. In the past floppy disks were maybe the only problem, but nowadays as storage is cheap more and more people use USB storage devices, and these are easy to unplug. It`s even worse if you have a laptop, since it`s easier to connect everything to a hub (mouse, hdds, other usb stuff) and connect/disconnect it. In the days before common storage devices (hard drives) where fixed inside the computer`s case, so unpluging a hard drive when the computer was running was considered as insane, so panicing is ok. Nowadays things have changed. USB (maybe Firewire too, have no experience with that) offers a simple way to connect/disconnect devices to your computer (here I have to note: not just one!), having a laptop and 1,2,3 or even more external storage devices is something usual. That`s why I think this particular problem needs to be addressed. Thanks for the tip about amd(8) I will give it a try. -- PGP KeyID: 0x3118168B Keyserver: pgp.mit.edu Key fingerprint BB50 2983 0714 36DC D02E 158A E03D 56DA 3118 168B ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removing external usb hdd without unmounting causes reboot?
On Wed, Jul 18, 2007 at 06:30:44PM +0200, Momchil Ivanov wrote: On Wednesday 18 July 2007 17:41:04 Oliver Fromme wrote: As Josh wrote, it's expected. The problem is known to exist for a long time already (probably as long as FreeBSD itself exists), and if there was an easy solution, certainly someone would have fixed it. I think this is a critical problem and needs to be addressed, avoiding it doesn`t solve it. I agree. I also have a hard time believing that the reason it hasn't been fixed is because there isn't an easy fix. I'm under the impression it hasn't been fixed because either no one cares enough to fix it (using the workaround as a scapegoat excuse), or because the majority of people do not use USB-based storage devices. All of this brings me back a few years when I went on a quest to write a application that interfaced with a Logitech USB webcam for FreeBSD (for a streaming fishtank camera). I found that USB alternative indexes were broken (the code was there, but did not work), which the camera relied upon. When I reported the issue to the FreeBSD USB stack maintainer at the time (who will remain nameless since he enjoyed arguing rather than fixing or working with me), I was told 2 things: I just ported this from NetBSD, don't blame me, Alt. indexes aren't commonly used so I don't really care. So, based on my experience as documented above, I would say the reasons I listed are dead on. Bottom line here is that the kernel panics when removing a USB device that has filesystems mounted. This shouldn't happen. Spitting out errors on the console is one thing, but a panic is another. Sometimes things cannot be avoided (re: unmount and you'll be fine), such as cats pulling on USB hub AC power cables and other such things. If someone wants to work on this and needs devices/toys (thumb drives, external enclosures + hard disks), let me know, I will be more than happy to buy them the hardware needed. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removing external usb hdd without unmounting causes reboot?
On Wed, Jul 18, 2007 at 10:05:59AM -0700, Jeremy Chadwick wrote: Bottom line here is that the kernel panics when removing a USB device that has filesystems mounted. s/USB // I also have a hard time believing that the reason it hasn't been fixed is because there isn't an easy fix. I'm under the impression it hasn't been fixed because either no one cares enough to fix it (using the workaround as a scapegoat excuse), or because the majority of people do not use USB-based storage devices. The reason is not the USB stack; the reason (IIRC) is that the FreeBSD VM was written with the default assumption that Devices Never Go Away. A large rewrite, I'm told, will be needed to fix this, and the code is convoluted and tricky. No one finds the situation acceptable; introducing the scapegoat word isn't going to win you any support. The problem is not a weekend's worth of work to fix, nor does it have anything to do with avoidance by one particular maintainer, which you apparently had encountered before. mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removing external usb hdd without unmounting causes reboot?
Nobody's said what the problem is. I'm not a filesystem code monkey, but IIRC, the problem is that the filesystem plays fast and loose with pointers and is too closely related to the VM. One solution is (as mentioned) a userland filesystem that doesn't panic. automount approximates this if you set the disconnect interval short ( 5 seconds). The other way to look at this, though, is the general goal of not panicing when it can be avoided. As a research OS, it's my feeling that BSD derived unixes have followed the if in doubt, panic regime. I don't think this is appropriate to a modern desktop or server OS. To my mind, an OS should only panic if there are indications of hardware corruption in a subsystem that can't be turned off. Ie: memory bad: panic; controller bad, turn off controller. In this particular case, we have unmount -f. If there are no dirty buffers, the USB system triggering the equivalent of unomunt -f should succeed. If we only mount usb devices async, this should be sufficient for most cases. If there are dirty buffers, what do we loose by just forgetting about them? The filesystem on the device is already as corrupt as its going to be... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removing external usb hdd without unmounting causes reboot?
On Wednesday 18 July 2007 19:34:06 Mark Linimon wrote: On Wed, Jul 18, 2007 at 10:05:59AM -0700, Jeremy Chadwick wrote: Bottom line here is that the kernel panics when removing a USB device that has filesystems mounted. s/USB // Just a dumb question: what does umount -f does? And doing something like that when a fs goes away shouldn`t fix it? If the problem is in general with a file system, regardless of the provider, then what does one do when a mounted smbfs becomes unavailable due to remote host down, no route to host or some other network related problems? Same question for NFS mounted filesystems? -- PGP KeyID: 0x3118168B Keyserver: pgp.mit.edu Key fingerprint BB50 2983 0714 36DC D02E 158A E03D 56DA 3118 168B pgpfXbuzcbviO.pgp Description: PGP signature
Re: Dell PERC5/i SAS5/5IR - RAID monitoring
Am 18.07.2007 um 16:34 schrieb Brian A. Seklecki: Hi Tom, thank you for your response. What about monitoring the PERC5/ie ? Does it work with megarc or any program under FreeBSD ? I have some scripts on nagiosexchange.org; wrappers around megacli (8) and megarc(8). ~BAS Cool :) Thank you very much. Best Regards Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removing external usb hdd without unmounting causes reboot?
Momchil Ivanov wrote: On Wednesday 18 July 2007 19:34:06 Mark Linimon wrote: On Wed, Jul 18, 2007 at 10:05:59AM -0700, Jeremy Chadwick wrote: Bottom line here is that the kernel panics when removing a USB device that has filesystems mounted. s/USB // Just a dumb question: what does umount -f does? And doing something like that when a fs goes away shouldn`t fix it? If the problem is in general with a file system, regardless of the provider, then what does one do when a mounted smbfs becomes unavailable due to remote host down, no route to host or some other network related problems? Same question for NFS mounted filesystems? !DSPAM:1,469e538b20763944420674! Wow, quite a thread going on over this issue. I'll throw my 2cents into the ring also :) From a desktop perspective, it makes total sense to not have the system crash just because a USB disk was unplugged while mounted. When a new end user does this for the first time and the system crashes, usually the first thing they assume is that it's a bug. Then somebody like me comes around and tells them to unmount it first. Then usually the next thing they say is something along the lines of That's so early 90's, why can't you guys get your act together? I can understand requiring unmounting for devices such as CD's or internal IDE / SCSI hard drives. With a CD at least you can physically lock the drive bay to prevent the user from ejecting until unmounted first. However, with a USB the ballgame changes, the whole concept is to be hot-swappable, plugin and unplug at will. If a normal desktop user copies a file to a USB disk and the file transfer dialog is done, then they should be able to unplug it, without a total system crash. That being said, I think it would be a good idea to at least have the kernel / HAL or some process maybe warn the user that they should unmount the USB disk first, to prevent data loss at minimum. But I think this can be improved, so you don't have to deal with an entire system panic :P When that happens you gotta reboot, fsck, and run the risk of something really being corrupted on the drive :( -- Kris Moore PC-BSD Software http://www.pcbsd.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removing external usb hdd without unmounting causes reboot?
On Wednesday 18 July 2007, Mark Linimon wrote: On Wed, Jul 18, 2007 at 10:05:59AM -0700, Jeremy Chadwick wrote: Bottom line here is that the kernel panics when removing a USB device that has filesystems mounted. s/USB // I also have a hard time believing that the reason it hasn't been fixed is because there isn't an easy fix. I'm under the impression it hasn't been fixed because either no one cares enough to fix it (using the workaround as a scapegoat excuse), or because the majority of people do not use USB-based storage devices. The reason is not the USB stack; the reason (IIRC) is that the FreeBSD VM was written with the default assumption that Devices Never Go Away. A large rewrite, I'm told, will be needed to fix this, and the code is convoluted and tricky. No one finds the situation acceptable; introducing the scapegoat word isn't going to win you any support. The problem is not a weekend's worth of work to fix, nor does it have anything to do with avoidance by one particular maintainer, which you apparently had encountered before. mcl Panicing really is the right thing to do with the current architecture. Not panicing when a mounted filesystem disappears runs the risk of corrupting other mounted filesystems. Mark is entirely correct, FreeBSD faces an architecture problem here in that the vm and filesystems we have today were not designed in an era when they could just disappear from a running system. The BSD way isn't to apply a quick and dirty little hack to fix the 'problem', it's to design the system properly. And this is assuming a quick and dirty hack even exists. The other problem you're running in to with UFS anyways is that there is no chance to 'unmount' the filesystem when you disconnect the drive. By the time anything has a chance to realize it's gone it's too late. Whether the disk is in the middle of a write, still has buffers to be written out, or is perfectly clean and needs to just be marked as such by the time the OS realizes any of that needs to be done the drive is no longer physically connected to the computer. What might need to happen is a redesign of the vm subsystem so that it can safely deal with mounted filesystems going away, and designing a filesystem that doesn't need to be unmounted specifically for removeable devices. Doesn't sound trivial to me. Or You can just not remove devices with mounted filesystems from your computer. -- Thanks, Josh Paetzel pgpBhbiMYM6HX.pgp Description: PGP signature
Re: Dell PERC5/i SAS5/5IR - RAID monitoring
On Wed, 18 Jul 2007, Michael Worobcuk wrote: Hi, Am 18.07.2007 um 16:34 schrieb Brian A. Seklecki: Hi Tom, thank you for your response. What about monitoring the PERC5/ie ? Does it work with megarc or any program under FreeBSD ? I have some scripts on nagiosexchange.org; wrappers around megacli(8) and megarc(8). ~BAS Cool :) Thank you very much. Also the ports for those utilities have periodic scripts that just need to be enabled in periodic.conf and give daily state and log changes for controllers. amr(4) and mfi(4) come to my mind as well as twa(4) which is not found in Dell servers. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removing external usb hdd without unmounting causes reboot?
Oliver Fromme wrote: Momchil Ivanov wrote: On Wednesday 18 July 2007 15:52:42 [LoN]Kamikaze wrote: Josh Paetzel wrote: Yes, it's expected behavior. The workaround is to not unplug mounted devices. (There's nothing special about USB here, if you unplugged an IDE drive you'd get the same behavior) Wouldn't it make some sense not to panic if mounted devices that are in sync get removed? A few applications might get in trouble, but that's hardly a reason to bring a whole system down. I don`t know how things work, but shutting down the system when some mounted fs is no longer present seems like the wrong thing to me. As Josh wrote, it's expected. The problem is known to exist for a long time already (probably as long as FreeBSD itself exists), and if there was an easy solution, certainly someone would have fixed it. I have to check this, but AFAIK this problem exists only for devices/partitions that are mounted R/W. Do you happen to know this? (I can not risk to crash my box right now for a test ;-) There once was an autofs implementation, but IIRC it has later been removed. It could not only automatically mount removable media, but it could also help with the problem of devices that are rarely written to, but still mounted R/W just in case for easy write-access. Long time ago I had the idea that a clean file system could be mounted R/O after a short delay. When all dirty buffers are flushed, the device could be forcefully disconnected without causing inconsistencies in the kernel. If there are no open file descriptors, the super-block could be written with the clean flag set, to signal that no fsck is needed when the partition is mounted next time. Internally, the device can be treated as R/O, with the only exeption that an attempted write is not rejected, but that it instead triggers the change back to R/W operation (this means setting the in-RAM copy of the super-block to dirty before the write is allowed to proceed as normal). Removable devices and dealing with a device that is gone and re-appears (either the same device or one that takes its place) needs special consideration, e.g. by checking a disk label and flushing cached blocks that were associated with the device that now is definitely gone. I had this idea back when floppy disks were common, but with USB memory sticks and devices the same situation exists ... The mode change to R/O could be triggered by a timer after the necessary condition exists (e.g. half a second after the last write to the device with no dirty buffers left). The system already knows whether there are dirty buffers for a partition, it is not hard to detect this case. The other parameter of interest is whether there are any open files on that partition (which decides whether the super-block can be marked as clean). This functionality could be implemented within an autofs as a special case (mount only R/O and upgrade only when needed and for as long as necessary), but I think it should be not too hard to add as a small in-kernel modification ... Regards, STefan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removing external usb hdd without unmounting causes reboot?
On Wed, Jul 18, 2007 at 11:54:19AM -0700, Kris Moore wrote: That being said, I think it would be a good idea to at least have the kernel / HAL or some process maybe warn the user that they should unmount the USB disk first, to prevent data loss at minimum. But I think this can be improved, so you don't have to deal with an entire system panic :P When that happens you gotta reboot, fsck, and run the risk of something really being corrupted on the drive :( So there's two issues here: 1) Kernel panics when a device (regardless of type (USB, SATA, etc.)) is removed from the system with filesystems mounted, 2) Concern over data loss when device is removed. As I mentioned earlier in the thread, Windows addresses #2 by marking all filesystems on USB storage devices (thumb drives, HDDs, etc.) as synchronous (e.g. mount -o sync). The impact is slow I/O, but it's safe. It seems like we'd be able to implement such a transparent feature into the subsystem where filesystems mounted from USB devices would use synchronous I/O (mount -o sync). I don't know how this would be coded, since there would have to be some way to figure out a physical device type (USB mass storage devices show up as /dev/daXXX). Providing an override option for those who know what they're doing, (umount /mnt then physically remove device) would be nice too. This would alleviate concerns over data loss, would it not? -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removing external usb hdd without unmounting causes reboot?
Zaphod Beeblebrox wrote: One solution is (as mentioned) a userland filesystem that doesn't panic. automount approximates this if you set the disconnect interval short ( 5 seconds). Unfortunately the approximation is far from perfect because it takes noticable time to mount a msdosfs on large drives (I think the FAT is being read?). The other way to look at this, though, is the general goal of not panicing when it can be avoided. As a research OS, it's my feeling that BSD derived unixes have followed the if in doubt, panic regime. I don't think this is appropriate to a modern desktop or server OS. Agreed very much, though some of the older hackers here seem to like the old approach. signature.asc Description: OpenPGP digital signature
Re: removing external usb hdd without unmounting causes reboot?
Jeremy Chadwick wrote: On Wed, Jul 18, 2007 at 11:54:19AM -0700, Kris Moore wrote: That being said, I think it would be a good idea to at least have the kernel / HAL or some process maybe warn the user that they should unmount the USB disk first, to prevent data loss at minimum. But I think this can be improved, so you don't have to deal with an entire system panic :P When that happens you gotta reboot, fsck, and run the risk of something really being corrupted on the drive :( So there's two issues here: 1) Kernel panics when a device (regardless of type (USB, SATA, etc.)) is removed from the system with filesystems mounted, 2) Concern over data loss when device is removed. As I mentioned earlier in the thread, Windows addresses #2 by marking all filesystems on USB storage devices (thumb drives, HDDs, etc.) as synchronous (e.g. mount -o sync). The impact is slow I/O, but it's safe. It seems like we'd be able to implement such a transparent feature into the subsystem where filesystems mounted from USB devices would use synchronous I/O (mount -o sync). I don't know how this would be coded, since there would have to be some way to figure out a physical device type (USB mass storage devices show up as /dev/daXXX). Providing an override option for those who know what they're doing, (umount /mnt then physically remove device) would be nice too. This would alleviate concerns over data loss, would it not? This sounds like an excellent idea to me. If something along these lines were implemented, it would be very helpful for us on the desktop end of things. -- Kris Moore PC-BSD Software http://www.pcbsd.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removing external usb hdd without unmounting causes reboot?
Josh Paetzel wrote: designing a filesystem that doesn't need to be unmounted specifically for removeable devices. Or just do what Windows does on its hard-drive-mounted NTFS and MSDOS file systems and mark it clean after several seconds of inactivity. This also helps solve other problems like power failures, laptop battery drainage (in its common form and when the battery dies while the system is suspened). signature.asc Description: OpenPGP digital signature
Re: removing external usb hdd without unmounting causes reboot?
Mark Linimon wrote: The reason is not the USB stack; the reason (IIRC) is that the FreeBSD VM was written with the default assumption that Devices Never Go Away. A large rewrite, I'm told, will be needed to fix this, and the code is convoluted and tricky. I also feel that the institutial knowledge about the VM+VFS+UFS conglomerate seems to be going away. There were many attempts to port file systems to FreeBSD that have stopped dead once they've reached read-only phase, and recent problems with UFS looked really ugly (I don't even know if they are solved - I'm scared of filling up UFS drives right now :) ). My first production ZFS panicked the other day so ZFS is not yet the answer. (And yes, I know I'm complaining without suggesting solutions). signature.asc Description: OpenPGP digital signature
Panic with umass (with USB tape and Amanda)
Hello everybody,
I have just had a panic on 6.2 amd64 box with ehci connected USB DDS4
tape drive while it was for the first time being accessed with Amanda. I
have previously successfully tested it with tar.
I have a kernel crash dump with the following information:
panic: trying to sleep while sleeping is prohibited
cpuid = 0
KDB: stack backtrace:
panic() at panic+0x250
sleepq_add() at sleepq_add+0x225
msleep() at msleep+0x132
bwait() at bwait+0x55
swap_pager_putpages() at swap_pager_putpages+0x45c
vm_pageout_flush() at vm_pageout_flush+0x13b
vm_contig_launder_page() at vm_contig_launder_page+0xdc
vm_page_alloc_contig() at vm_page_alloc_contig+0x321
contigmalloc() at contigmalloc+0x5f7
bus_dmamem_alloc() at bus_dmamem_alloc+0x80
usb_block_allocmem() at usb_block_allocmem+0x118
usb_allocmem() at usb_allocmem+0x13e
usbd_transfer() at usbd_transfer+0xf1
umass_setup_transfer() at umass_setup_transfer+0x3b
umass_bbb_state() at umass_bbb_state+0xc0
usb_transfer_complete() at usb_transfer_complete+0x217
uhci_softintr() at uhci_softintr+0x100
uhci_intr1() at uhci_intr1+0x152
ithread_loop() at ithread_loop+0x148
fork_exit() at fork_exit+0xbb
fork_trampoline() at fork_trampoline+0xe
bt full
#0 0x8027ca40 in shutdown_conf (unused=0x0)
at ../../../kern/kern_shutdown.c:138
No locals.
#1 0x8027d304 in boot (howto=-2004318071)
at ../../../kern/kern_shutdown.c:209
_ep = (struct eventhandler_entry *) 0x0
_el = (struct eventhandler_list *) 0xff007b84c800
first_buf_printf = 1
#2 0x8027cd9b in panic (
fmt=0x803dfa78 trying to sleep while sleeping is
prohibited)
at ../../../kern/kern_shutdown.c:542
bootopt = 260
newpanic = 1
ap = {{gp_offset = 8, fp_offset = 48,
overflow_arg_area = 0xb197a650,
reg_save_area = 0xb197a570}}
buf = trying to sleep while sleeping is prohibited, '\0'
repeats 211 times
#3 0x8029f02a in sleepq_switch (wchan=0x0)
at ../../../kern/subr_sleepqueue.c:447
No locals.
#4 0x8028337c in msleep (ident=0x80560b40, mtx=0x0,
priority=68, wmesg=0x803ef69a swwrt, timo=0)
at ../../../kern/kern_synch.c:133
p = (struct proc *) 0x9f826428
catch = 0
rval = -2141828960
flags = -2141828960
#5 0x802cd1d6 in vfs_unbusy_pages (bp=0x803ef69a)
at ../../../kern/vfs_bio.c:3227
i = 0
obj = 0x1
m = 0x9f826428
#6 0x8034b691 in swap_pager_copy
(srcobject=0xff007fd8a570,
dstobject=0x0, offset=18446742974451804800, destroysource=-1)
at ../../../vm/swap_pager.c:766
i = 18446744072394090256
#7 0x80361a70 in vm_pageout_object_deactivate_pages (
pmap=0xb197a810, first_object=0xff000f21ea80,
desired=-1315461200) at ../../../vm/vm_pageout.c:539
backing_object = 0x802cd1d6
object = 0x1
p = 0x802cd1d6
next = 0xb197a710
actcount = -1
rcount = 0
remove_mode = -1315461232
#8 0x80351338 in vm_page_release_contigl
(m=0xff000f21ea80,
count=18446742976342828400) at ../../../vm/vm_contig.c:353
No locals.
#9 0x803518b3 in contigmalloc (size=0, type=0x,
flags=-256,
low=32768, high=1048575, alignment=505970,
boundary=18446742976282112000)
at ../../../vm/vm_contig.c:579
ret = (void *) 0x7b872
pages = 0x1
npgs = 4503560972664832
#10 0x80352040 in contigmalloc (size=0,
type=0x80521d20,
flags=1, low=0, high=4294967295, alignment=0, boundary=0)
at ../../../vm/vm_contig.c:546
ret = (void *) 0x0
pages = 0xff0076a46860
npgs = 8
#11 0x80368f3d in alloc_bounce_pages (dmat=0x0,
numpages=1457574160)
at ../../../amd64/amd64/busdma_machdep.c:1061
---Type return to continue, or q return to quit---
bpage = (struct bounce_page *) 0x1
bz = (struct bounce_zone *) 0xff000978ed00
count = 1
#12 0x802379ff in usb_block_allocmem (tag=0xff0056e0d100,
size=0,
align=32768, dmap=0xff0076a46860)
at ../../../dev/usb/usb_mem.c:187
p = (usb_dma_block_t *) 0x0
#13 0x80237bba in usb_allocmem (bus=0x0, size=32768, align=0,
p=0xff0076a46860) at ../../../dev/usb/usb_mem.c:248
tag = 0x0
err = USBD_NORMAL_COMPLETION
f = (struct usb_frag_dma *) 0x0
b = (usb_dma_block_t *) 0xb197aaa0
i = 0
#14 0x80239c5a in usbd_transfer (xfer=0xff0076a46800)
at ../../../dev/usb/usbdi.c:311
bus = (struct usbd_bus *) 0x0
pipe = 0xff00132bb500
err = 1540196352
size = 32768
#15 0x80233fa9 in umass_setup_transfer (sc=0x0, pipe=0x0,
buffer=0x0,
buflen=0, flags=0, xfer=0xff0076a46800)
at ../../../dev/usb/umass.c:1252
err = USBD_NORMAL_COMPLETION
#16 0x802344c0 in
SCSI error during boot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi When I boot my FreeBSD 6.2-RELEASE-p6, I get the following error: (pass0:ahc0:0:0:0): Vendor Specific Command. CDB: 85 8 e 0 0 0 1 0 0 0 0 0 0 0 e c 0 (pass0:ahc0:0:0:0): CAM Status: SCSI Status Error (pass0:ahc0:0:0:0): SCSI Status: Check Condition (pass0:ahc0:0:0:0): ILLEGAL REQUEST asc:20,0 (pass0:ahc0:0:0:0): Invalid command operation code: Command byte 0 is invalid (pass0:ahc0:0:0:0): Vendor Specific Command. CDB: 85 8 e 0 0 0 1 0 0 0 0 0 0 0 a 1 0 (pass0:ahc0:0:0:0): CAM Status: SCSI Status Error (pass0:ahc0:0:0:0): SCSI Status: Check Condition (pass0:ahc0:0:0:0): ILLEGAL REQUEST asc:20,0 (pass0:ahc0:0:0:0): Invalid command operation code: Command byte 0 is invalid camcontrol gives this output: pass0: QUANTUM ATLAS_V_18_WLS 0230 Fixed Direct Access SCSI-3 device pass0: Serial Number 141014450327 pass0: 40.000MB/s transfers (20.000MHz, offset 63, 16bit), Tagged Queueing Enabled dmesg regarding the controller: ahc0: Adaptec 29160N Ultra160 SCSI adapter port 0x8800-0x88ff mem 0xdb00-0xdb000fff irq 16 at device 12.0 on pci0 ahc0: [GIANT-LOCKED] aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs smartctl shows no errors on the disk, but this error occur: (pass0:ahc0:0:0:0): MODE SENSE(06). CDB: 1a 0 19 0 40 0 (pass0:ahc0:0:0:0): CAM Status: SCSI Status Error (pass0:ahc0:0:0:0): SCSI Status: Check Condition (pass0:ahc0:0:0:0): ILLEGAL REQUEST asc:24,0 (pass0:ahc0:0:0:0): Invalid field in CDB: Command byte 2 is invalid I tried booting the server on a Fedora 7 Live cd, ran smartctl and got no error, so I assume the error is in the FreeBSD drivers. How do I proceed, to get a fix for this problem? - -- Med venlig hilsen - Sincerely Uffe R. B. Andersen - mailto:[EMAIL PROTECTED] http://www.twe.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (MingW32) iD8DBQFGnoWJxC95nUQcrpgRAoE9AJ9VPpWjtx1dZgbXWzjJORhE2TTYSwCZAZGz E6Nr9QBx2DtznuOxJ7Xl1tk= =kY06 -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removing external usb hdd without unmounting causes reboot?
On 18 Jul, Momchil Ivanov wrote: If the problem is in general with a file system, regardless of the provider, then what does one do when a mounted smbfs becomes unavailable due to remote host down, no route to host or some other network related problems? Same question for NFS mounted filesystems? In the case of NFS, nothing happens if the filesystem is idle. If the filesystem is active, any pending operations are retried indefinitely by periodically resending the I/O requests if the file system is hard mounted. If the filesystem is soft mounted, then the I/O requests are eventually timed out with the appropriate error status returned to the process on the client. An important difference between NFS and UFS is that a loss of network connectivity (or a clean server reboot) can't cause any filesystem inconsistencies in the NFS case because complex filesystem operations that require multiple disk operations are treated as atomic operations between the client and server. For example, creating a new directory requires a number of physical disk writes in the UFS case, and unplugging the disk in the middle would result in an inconsistent filesystem state. In the NFS case, creating a new directory only requires only one NFS operation over the wire, and the client is allowed to keep retrying the operation until it receives a status response from the server. Retries might be necessary if either the request or the response packet was dropped by the network, the server crashed, etc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCSI error during boot
On Wed, Jul 18, 2007 at 11:26:33PM +0200, Uffe R. B. Andersen wrote:
When I boot my FreeBSD 6.2-RELEASE-p6, I get the following error:
(pass0:ahc0:0:0:0): Vendor Specific Command. CDB: 85 8 e 0 0 0 1 0 0 0 0 0 0
0 e c 0
(pass0:ahc0:0:0:0): CAM Status: SCSI Status Error
(pass0:ahc0:0:0:0): SCSI Status: Check Condition
(pass0:ahc0:0:0:0): ILLEGAL REQUEST asc:20,0
(pass0:ahc0:0:0:0): Invalid command operation code: Command byte 0 is invalid
{snip}
pass0: QUANTUM ATLAS_V_18_WLS 0230 Fixed Direct Access SCSI-3 device
Your drive is a Quantum/Maxtor/Seagate Atlas V (presumably 10Krpm).
Based on the following SCSI 2 implementation specification, the drive
does not support SCSI operation code 0x85; see section 5.0 table 35 in
the below PDF. ASC 0x20 0x00 for this drive means Invalid Command
Operation Code; see section 5.34.3 of the below PDF:
http://seagate.com/support/disc/manuals/scsi/38479j.pdf
According to the official T10 documentation, operation code 0x85 is for
ATA pass-through capability:
http://t10.t10.org/ftp/t10/document.04/04-262r8.pdf
However, there's mention of this command on some Linux mailing lists,
and seems to imply that revision of documentation is wrong:
http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/88b473fabed044b5/20069c720cde3325?lnk=stq=scsi+0x85+commandrnum=8hl=en#20069c720cde3325
...and that command 0x85 on SCSI-3 should do nothing. See Annex D,
or page 427 here:
http://www.t10.org/ftp/t10/drafts/spc3/spc3r21c.pdf
Either way, none of this appears to be a controller problem.
The bottom line here is that your drive doesn't support a specific SCSI
command that's being submit to it. In this case, it looks to be harmless.
smartctl shows no errors on the disk, but this error occur:
(pass0:ahc0:0:0:0): MODE SENSE(06). CDB: 1a 0 19 0 40 0
(pass0:ahc0:0:0:0): CAM Status: SCSI Status Error
(pass0:ahc0:0:0:0): SCSI Status: Check Condition
(pass0:ahc0:0:0:0): ILLEGAL REQUEST asc:24,0
(pass0:ahc0:0:0:0): Invalid field in CDB: Command byte 2 is invalid
That should only occur when you run smartctl. SCSI operation
code 0x1a is Mode Sense (which the drive supports; see section 5.12).
But you have to break it down into sub-commands:
Byte 2 = %00011001
PCF = %00 (Return current values)
Page Code = 0x19 (SCSI Port Control Mode page)
The drive claims to support this, but I don't know what it does. :-)
ASC 0x24 0x00 for this drive means Invalid Field in CDB. Possibly
this is a drive firmware bug or simply an implementation difference;
I've seen similar reports from Seagate drives on Solaris when using
smartctl -a /dev/rdsk/whatever. The SMART results are shown, but it
throws an invalid CDB error on the console.
I tried booting the server on a Fedora 7 Live cd, ran smartctl and got
no error, so I assume the error is in the FreeBSD drivers.
How do I proceed, to get a fix for this problem?
It's not a problem, but admittedly it should be fixed somehow. The
SCSI errors you get when using smartctl are something to discuss with
Bruce Allen (author of smartmontools):
http://smartmontools.sourceforge.net/
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removing external usb hdd without unmounting causes reboot?
On Wednesday 18 July 2007 21:03:10 Josh Paetzel wrote: On Wednesday 18 July 2007, Mark Linimon wrote: On Wed, Jul 18, 2007 at 10:05:59AM -0700, Jeremy Chadwick wrote: Bottom line here is that the kernel panics when removing a USB device that has filesystems mounted. s/USB // I also have a hard time believing that the reason it hasn't been fixed is because there isn't an easy fix. I'm under the impression it hasn't been fixed because either no one cares enough to fix it (using the workaround as a scapegoat excuse), or because the majority of people do not use USB-based storage devices. The reason is not the USB stack; the reason (IIRC) is that the FreeBSD VM was written with the default assumption that Devices Never Go Away. A large rewrite, I'm told, will be needed to fix this, and the code is convoluted and tricky. No one finds the situation acceptable; introducing the scapegoat word isn't going to win you any support. The problem is not a weekend's worth of work to fix, nor does it have anything to do with avoidance by one particular maintainer, which you apparently had encountered before. mcl Panicing really is the right thing to do with the current architecture. Not panicing when a mounted filesystem disappears runs the risk of corrupting other mounted filesystems. Mark is entirely correct, FreeBSD faces an architecture problem here in that the vm and filesystems we have today were not designed in an era when they could just disappear from a running system. The BSD way isn't to apply a quick and dirty little hack to fix the 'problem', it's to design the system properly. And this is assuming a quick and dirty hack even exists. The other problem you're running in to with UFS anyways is that there is no chance to 'unmount' the filesystem when you disconnect the drive. By the time anything has a chance to realize it's gone it's too late. Whether the disk is in the middle of a write, still has buffers to be written out, or is perfectly clean and needs to just be marked as such by the time the OS realizes any of that needs to be done the drive is no longer physically connected to the computer. I think you are missing the point here and it is that the drive is already gone, so you do not have to care about it. The state of the drive`s filesystem is of no interest since you cannot to anything to change it any more. The point is that the drive is gone. If you were in the middle of a write, you just return an error (like your disk is going physically bad/ some broken cable issue... for instance) and forget about the data you wanted to write, the drive is not there any more. Maybe I am naive and uneducated enough (don`t know how freebsd does things, nor am I a programmer) but I will give my 2 stotinki here. The most natural way for me seems to be that the OS should just return errors to the programs trying any I/O on that drive. May be when a drive is unplugged the OS has to mark it and the mounted file systems as not being there until all opened files on it are closed, return errors for all I/O except for closing opened files. And when all files are closed consider the fs as unmounted and remove the drive from the kernel. This is my idea of how things should be done. Ensuring that a file system is in a consistent state after drive disconnect is something completely different (wanted to discuss just disconnecting devices, not filesystems that can be disconnected without unmount, not ensuring fully operational file system even it a case of disconnected drive). One can try to implement something here (as mentioned in some of the replies), but not necessary. If the user has unpluged the device without unmounting it first he might be left with a broken file system on that drive, we cannot do anything, so we should not care about it, it`s his mistake and his fs fucked up. The point is that unpluging should not lead to system crash, which is in my opinion critical system error. I as user I should be able to unplug any external device without crashing the OS. Doing this and thus leaving me with a broken filesystem or some other device issues should be considered my error. Thus I should learn the hard way to unmount first. Designing a filesystem or some hacks to ensure consistent state after disconnect should not be in the scope of this thread and problem, I think. What might need to happen is a redesign of the vm subsystem so that it can safely deal with mounted filesystems going away, and designing a filesystem that doesn't need to be unmounted specifically for removeable devices. Doesn't sound trivial to me. Or You can just not remove devices with mounted filesystems from your computer. -- PGP KeyID: 0x3118168B Keyserver: pgp.mit.edu Key fingerprint BB50 2983 0714 36DC D02E 158A E03D 56DA 3118 168B ___ freebsd-stable@freebsd.org mailing
Adding /dev/random and /dev/urandom to a jail.
Hi, I am running 6.2 and I am having problems getting /dev/random to work inside a jail. What is the proper technique for creating /dev/random and /dev/urandom inside a jail? Thanks, Tony ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Properly managing SpamAssassin. . .
On Wed, 18 Jul 2007 11:05:25 -0400
Michael Williams [EMAIL PROTECTED] wrote:
Hi All,
I'm looking for a way to properly manage SpamAssassin after Plesk has
wreaked havoc on the server.
Hi Michael,
i think this thread doesnt belong in stable@, but questions@ - i dont see how
this refers to one particular version of freebsd in particular.
In the short term, we need to keep
Plesk around for those that need the ease of use. However, it
wants to keep resetting values, etc; meaning that since the Plesk
license doesn't support SpamAssassin it won't allow us to use it
and wants it to remain that way. If push comes to shove, I *will*
blast Plesk. That said, I need to figure out the proper way to
enable SpamAssassin and have Qscan work properly, circumventing the
Plesk activites and licensing limitations. Does anyone have any
quality insight into the most up-to-date means for accomplishing this?
Caveat : I only suffer plesk in Linux, but the issues are very similar.
I dont know of any way to bypass the licensing limitations... i strongly
suggest if you walked into those you simply get rid of plesk now.
I am not sure for SA, but there is a version of qscan that supports passing the
email to Clamav:
http://www.hostbird.com/beta/index.php?loc=0602-0602
Maybe there is something out there to support SA? Or simply configure qmail to
support SA - you wont get an interface to manage SA from plesk, but you aren't
missing much, IMHO - most of our users dont care about custom spam/ham , but
rely on the system wide bayes list.
(qmail is another reason to move away from plesk, imho... :( )
_
{Beto|Norberto|Numard} Meijome
Liberty is not a means to a higher political end. It is itself the highest
political end...
liberty is the only object which benefits all alike, and provokes no sincere
opposition...
The danger is not that a particular class is unfit to to govern. Every class is
unfit to govern...
Power tends to corrupt, and absolute power corrupts absolutely.
Lord Acton
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding /dev/random and /dev/urandom to a jail.
Tech Valley Internet - Tony Kivits wrote: Hi, I am running 6.2 and I am having problems getting /dev/random to work inside a jail. What is the proper technique for creating /dev/random and /dev/urandom inside a jail? Have you mounted devfs in the jail? signature.asc Description: OpenPGP digital signature
Re: removing external usb hdd without unmounting causes reboot?
On Wed, 18 Jul 2007 17:41:04 +0200 (CEST)
Oliver Fromme [EMAIL PROTECTED] wrote:
If you have problems remembering,
This is very interesting thread indeed
I have found that mounting remote SMB shares will panic the kernel too, but
only if i try to access it while 'gone' . If I remember correctly, if i thread
carefully around it, i can manage to shutdown everything and it will only panic
at the very last minute when the kernel tries to unmount.
And, from my point of view, the explanation 'well, don't remove your mounted
devices without unmounting them first' is rubbish - the problem is not
necessarily users removing them, but ALL the reasons that could cause an
unwanted and unplanned removal. Like a network outage in the case of smbfs. or
someone killing the power on a USB device. I can't see why the whole kernel
should die on you. Yes, i understand there are architectural reasons for this -
then the architecture is not right anymore, i think.
another work-around
is to use the auto mounter daemon (amd(8)). It umounts
file systems automatically that are not in use.
Another nice feature of amd(8) is that you don't have
to mount the file system either -- Simply plug the USB
stick in, then access it, and amd(8) will automatically
mount it for you.
Now, something I dont understand - amd runs
at user level, and it mounts filesystems, and nothing dies when the filesystems
go away (other than the obvious cases for the applications trying to write to
the FS in question). Doesn't amd , at some point , have to tell the kernel
'please mount this filesystem' here or there? Isn't the kernel STILL involved
in all this? and why doesnt the kernel panic when the FS goes away?
The same goes for hald - it doesn't work flawlessly, but it does the trick, and
i cant recall an instance when it crashed the kernel.
re. USB disks, could we not by default use amd to mount USB devices? It seems
the obvious native replacement for hald + polkitd + dbus I use in XFCE with
Thunar on my laptop...
TIA!
_
{Beto|Norberto|Numard} Meijome
Never attribute to malice what can adequately be explained by incompetence.
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding /dev/random and /dev/urandom to a jail.
Yes but the random devices are not showing up there. I am trying the suggestions from Christopher Cowart to see if that will get them to show up. Thanks, Tony At 07:40 PM 7/18/2007, Ivan Voras wrote: Tech Valley Internet - Tony Kivits wrote: Hi, I am running 6.2 and I am having problems getting /dev/random to work inside a jail. What is the proper technique for creating /dev/random and /dev/urandom inside a jail? Have you mounted devfs in the jail? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
webmin adding to many groups to www group
Hello all i am having trouble getting virtualmin to work right with freebsd 6.2 stable and apache 2.2.4. I believe my problem is related to having to many groups in the www group. see below king1::1007:www king2::1012:www king3::1011:www king4::1013:www king5::1010:www king6::1017:www king7::1014:www king8::1016:www king9::1015:www king10::1018:www king11::1020:www king12::1019:www king13::1020:www When i try to add another group king14::1021:www I get this error in apache [Wed Jul 18 20:23:08 2007] [notice] Graceful restart requested, doing restart [Wed Jul 18 20:23:09 2007] [warn] NameVirtualHost *:80 has no VirtualHosts [Wed Jul 18 20:23:09 2007] [warn] (22)Invalid argument: Failed to enable the 'httpready' Accept Filter [Wed Jul 18 20:23:09 2007] [notice] Digest: generating secret for digest authentication ... [Wed Jul 18 20:23:09 2007] [notice] Digest: done [Wed Jul 18 20:23:10 2007] [notice] Apache/2.2.4 (FreeBSD) DAV/2 PHP/5.2.2 with Suhosin-Patch mod_ssl/2.2.4 OpenSSL/0.9.7e-p1 configured -- resuming normal operations [Wed Jul 18 20:23:10 2007] [alert] (22)Invalid argument: initgroups: unable to set groups for User www and Group 80 [Wed Jul 18 20:23:10 2007] [alert] Child 12628 returned a Fatal error... Apache is exiting! [Wed Jul 18 20:23:10 2007] [alert] (22)Invalid argument: initgroups: unable to set groups for User www and Group 80 [Wed Jul 18 20:23:10 2007] [alert] (22)Invalid argument: initgroups: unable to set groups for User www and Group 80 I did some googling and found this article http://lists.freebsd.org/pipermail/freebsd-bugs/2005-March/011831.html. What is the best way to set this up as i do not what users to be able to see each others directories but apache must be able to see them all right? is the a way to just add each user to the www group instead of creating a group for each user then adding that group to the www group. I think that is what webmin is doing right? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD violates RFC2870 [was: Re: Problems with named default configuration in 6-STABLE]
On Tue, Jul 17, 2007 at 12:47:50PM +0200, Volker wrote: As I think having a default to hint root zone is better, I'll file a PR about that. Which leads me to ask: Why hasn't anyone recommended using stub zones for this? It seems the goal is to cache NS records from the rootservers, and stub zones don't utilise AXFR/IXFR. Because a root server (stealth slave) can generate the NXDOMAIN responses locally. This really is a big win for ISP's where there are lots of leaked queries for private tlds, IPv4 addresses etc. Whether there is a benefit for everyone is still open to debate. Mark -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with named default configuration in 6-STABLE
On 07/17/07 11:06, Heiko Wundram (Beenic) wrote: On Tuesday 17 July 2007 10:52:43 Volker wrote: snip Relying on a zone transfer doesn't seem to be reliable to me as more than half of the root servers doesn't reply to AXFR requests. I've heard pretty much the same thing as you did wrt. root name servers denying AXFR, but as it works (TM), I don't see a reason not to use it. A nd it seems that the author of the FreeBSD default named.conf thought likewise , which is pretty okay with me (from the experience I gathered this morning). By the way: using the roots as hints only adds to the number of requests yo ur server has to do in order to retrieve first-level domain name servers, so i n the end, the transmitted data should be way higher than doing one AXFR to find them (simply because you'll see a large subset of those toplevel domai ns being requested when you're publically offering a DNS server). And the data is also cached on an AXFR in persistant storage, which is another major benefit (for me). Remember, AXFR requires a TCP transfer and not every firewall will happily let it pass. Then the firewall is misconfigured. Ordinary DNS lookups can require TCP. That's what the tc flag is for. I (partially) agree to the speedup effects you mentioned but if just 5 out of 13 root servers support AXFR, your bind will sit for a while to find a root server responding to it's AXFR requests. That may eat up your speed improvements. Type hint for the root zone always works (regardless of the firewall and which root server is being queried). Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with named default configuration in 6-STABLE
--nextPart2302559.jWhKoKUfrP
Content-Type: text/plain;
charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On Tuesday, 17. July 2007, Volker wrote:
On 07/17/07 09:20, Michael Nottebrock wrote:
On Tuesday, 17. July 2007, Yuri Pankov wrote:
On Mon, Jul 16, 2007 at 11:19:41PM +0200, Michael Nottebrock wrote:
I finally updated my desktop from 5.5-RELEASE to 6-STABLE. This got me
a new named.conf, which I modified to run named as a local resolver,
like I had before:
listen-on { 127.0.0.1; };
listen-on-v6{ ::1; };
forward only;
forwarders {
192.168.8.1;
};
Everything else is default. However, with this default configuration,
named will not resolve any hosts of my local domain (my.domain), which
uses addresses in the 192.168.8 subnet. My dns server on 192.168.8.1,
running 6.2-RELEASE, has a very simple dynamic dns setup: a zone
my.domain and a reverse zone 8.168.192.in-addr.arpa which are both
dynamically updated by dhcpd.
To make this work again, I had to delete everything in the default
named.conf from /* Slaving the following zones from the root
[...] to zone ip6.int { type master;
file master/empty.db; };.
I'm a DNS n00b, but I suspect that such drastic measures shouldn't be
required and somehow my setup is flawed. What can I do to make this
work right?
Cheers,
--
,_, | Michael Nottebrock | [EMAIL PROTECTED]
(/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org
\u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org
Hi Michael,
If I understood you correctly, you can't resolve 8.168.192.in-addr.arpa
anymore, and the line below (from default named.conf) is the cause:
zone 168.192.in-addr.arpa { type master; file master/empty.db; };
Yes - and this:
zone . {
type slave;
The root zone MUST be of type hint. You do not want to be a slave of
the root... don't you? ;)
The new default configuration of named wants me to be.
But now that you've mentioned it, I finally saw the following lines in the=
=20
default named.conf:
=2D--
If you do not wish to slave these zones from the root servers
use the entry below instead.
zone . { type hint; file named.root; };
=2D--
I scanned over that before, but being a DNS n00b, I didn't understand what =
it=20
meant. So, that solves that. Still, quite a bit of editing required:=20
Commenting out the slaved root zone, moving out the root servers hint out o=
f=20
a comment and commenting out the empty zone for my private use network to=20
make reverse lookups work again.
I think at least an UPDATING entry and maybe some more verbose and less=20
technical commenting in named.conf itself is warranted.
=2D-=20
,_, | Michael Nottebrock | [EMAIL PROTECTED]
(/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org
\u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org
--nextPart2302559.jWhKoKUfrP
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (FreeBSD)
iD8DBQBGnHiIXhc68WspdLARAuSHAKCk7dskkSAzlAiquA48iGvGf+B88ACeOoj4
XfDcTp42hWrF4RFOnG1jE8c=
=bto6
-END PGP SIGNATURE-
--nextPart2302559.jWhKoKUfrP--
For a forward zone to work there has to be a zone cut between any
authoritative zones (master/slave) and the forward zone.
When you graft private namespaces onto the DNS tree slave / stubs
zones work better.
Forward zones and forwarders are over used.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
