Re: nspluginwrapper: postinstallation
On Fri, Apr 06, 2007 at 09:01:52PM +0100, Rob Andrews wrote: > On 06-Apr-2007 17:21.24 (BST), Jerome BENOIT wrote: > > I have just tried to install nspluginwrapper: > > what is not clear to me is how to install a 32bit plugin afterward. > > I guess that we must do it by hand, so I tried to install one plugin > > (acroread 7.0.8): iceweasel froze ! > > > > Any success story is welcomed. > > I wrote a quick guide on how to use nspluginwrapper. It can be found in: > > /usr/share/doc/nspluginwrapper/README.Debian > > Really, all you want to do is install the plugin somewhere (I use > $HOME/.mozilla/plugins32) and then run: > > nspluginwrapper -i $HOME/.mozilla/plugins32/ > > Then restart your browser. > > If you have any problems with the package please feel free to email me. Hi Do you know if this works with the java plugins in ia32-sun-java5-bin ? when I run it I get not a valid NPAPI plugin Alex > > -- > rob andrews :: pgp 0x01e00563 :: [EMAIL PROTECTED] > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > signature.asc Description: Digital signature
Re: Plugins
On Mon, May 14, 2007 at 07:51:07PM +0200, Michelle Konzack wrote: > Am 2007-05-03 23:05:49, schrieb Pepo: > > Hi friends. > > > > Please, How do I can use plugins in Iceweasel if I am using Lenny-AMD64? > > (java, flash player) > > > > Thanks. > > > - END OF REPLIED MESSAGE - > > Why not use the nsplugingwraper which is in Debian? > Whit this wraper you can run 32bit plugins on amd64. does that include the java plugin as well ? > > Thanks, Greetings and nice Day > Michelle Konzack > Systemadministrator > Tamay Dogan Network > Debian GNU/Linux Consultant > > > -- > Linux-User #280138 with the Linux Counter, http://counter.li.org/ > # Debian GNU/Linux Consultant # > Michelle Konzack Apt. 917 ICQ #328449886 >50, rue de Soultz MSN LinuxMichi > 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) signature.asc Description: Digital signature
Re: Offtopic : Large hostings and colocations ¿w here?
Igor TAmara <[EMAIL PROTECTED]> writes: > P.D:Do you have a recommendation about buying computers that can > hold 2Tb of space? would it be possible to have a server of that > less than U$3000. I saw Dell 1430SC, but I would like to know if > there are similar options I recently bought 2 systems each 4TB SATA (8*500GB), software RAID5 on Marvel "Raid" card, 2 Opteron, x2 cores CPUs, 4GB RAM. 2U form factor. US$5k each. Your price point should be obtainable. Some resulting bonnie++ benchmarks: http://www.phy.bnl.gov/computing/index.php/Cluster_Disks Because of my email address I technically can't endorse the vendor but go to www.aslab.com and play with the configurations to get an idea of what is possible. -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpt_i2o and i2o_block on amd64 etch
On Monday 14 May 2007 12:56, Neil Gunton wrote: > I can forward Mark's email address (and the last version of the dpt_i2o > driver he sent me) to anyone who's interested. Yes, I would appreciate that. Thanks! cmr -- Debian 'Etch' - Registered Linux User #241964 "More laws, less justice." -- Marcus Tullius Ciceroca, 42 BC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpt_i2o and i2o_block on amd64 etch
Lennart Sorensen wrote: On Mon, May 14, 2007 at 12:28:10PM -0500, Neil Gunton wrote: Thanks, that's useful. I will probably end up installing using the i2o_block (if that turns out to be possible) and then roll my own using dpt_i2o. Somehow using the "official" Adaptec driver feels better. I have no idea why it wasn't included as the "official" driver... it's been working flawlessly for me since mid-2005. Not one disk error (that I can see). Well certainly when I last looked a couple of years ago, using the dpt driver on 64bit simply wasn't an option because the code wasn't 64bit compatible. Maybe there are patches to fix it, or maybe someone actually fixed it since. Not sure. In 2005, when I was going through the original issue, I somehow managed to get in touch with Mark Salyzyn at Adaptec. He emailed me the source code for the dpt_i2o driver, which had been tweaked to work with the 2.6 AMD64 kernel. Just a couple of weeks ago he emailed me the latest version of this, so obviously they are still maintaining it internally, if on an unofficial basis. Mark had told me back in 2005 that the dpt_i2o version was never accepted into the official kernel because the community had apparently already decided that i2o_block was somehow better, and it wouldn't be good to have two drivers that do essentially the same thing. I always thought this was rather sad, especially given that there were always doubts about the reliability of i2o_block. In this most recent email I got from him (weeks ago), he said that the maintainer of the i2o_block driver had removed himself from the maintenance list, so the driver's future was in doubt. That's second-hand conjecture, though. I can forward Mark's email address (and the last version of the dpt_i2o driver he sent me) to anyone who's interested. In a nutshell, dpt_i2o works just fine on AMD64, I've been using it 24/7 on a relatively busy website (upward of 50,000 page requests per day, MySQL, apache, 450,000 pics all on the one server, RAID10) for two years, not a peep out of the hard drives that I can see. Also, I think I remember Mark mentioning that dpt_i2o might be a little faster than i2o_block. Finally, you get familiar /dev/sda devices rather than the weird ones that i2o_block gives you (not that that really matters, but I prefer standard names whenever possible). Thanks again, /Neil -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Offtopic : Large hostin gs and colocations ¿where?
Hello Igor, Am 2007-05-11 08:54:51, schrieb Igor TAmara: > Hi, I would like to know if there are services offering machines > with about 2teras of space and 20mbps of bandwidth, I guess with no > monthly limit. In my country, Colombia, we don't have ISP that can > offer this kind of things in a moderately way. I had the problem too and a 2 TB Server in colo WILL kill your resources! > Do you have a recomendation about where can I have a dedicated > server, or colocation with this info? Look for an ISP where you can have a WHOLE 19"/42U Unit and install YOUR OWN server. > P.D:Do you have a recommendation about buying computers that can > hold 2Tb of space? would it be possible to have a server of that > less than U$3000. I saw Dell 1430SC, but I would like to know if > there are similar options I do not know what your reauirements are, but 3000 US$ and 2 TB do not sounds like an SCSI-System... My Main-Database is now a Drive-Rack with 3+1 x 18GB (Raid-5 + Hotspare, System) and 10+1 147 GB (Raid-5 + Hotspare, /var/lib/postgre). This system is a little bit about 16.000 Euro. For the 19"/42U I pay 100 Euro/month + Electricity + Traffic. In summary, arround 400 Euro per month. And now I have five 4U Servers there. Bandwidth is 1 Gbit. Location is germany. Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSN LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Plugins
Am 2007-05-03 23:05:49, schrieb Pepo: > Hi friends. > > Please, How do I can use plugins in Iceweasel if I am using Lenny-AMD64? > (java, flash player) > > Thanks. > - END OF REPLIED MESSAGE - Why not use the nsplugingwraper which is in Debian? Whit this wraper you can run 32bit plugins on amd64. Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSN LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: dpt_i2o and i2o_block on amd64 etch
On Mon, May 14, 2007 at 12:28:10PM -0500, Neil Gunton wrote: > Thanks, that's useful. I will probably end up installing using the > i2o_block (if that turns out to be possible) and then roll my own using > dpt_i2o. Somehow using the "official" Adaptec driver feels better. I > have no idea why it wasn't included as the "official" driver... it's > been working flawlessly for me since mid-2005. Not one disk error (that > I can see). Well certainly when I last looked a couple of years ago, using the dpt driver on 64bit simply wasn't an option because the code wasn't 64bit compatible. Maybe there are patches to fix it, or maybe someone actually fixed it since. Not sure. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpt_i2o and i2o_block on amd64 etch
On Mon, May 14, 2007 at 11:56:03AM -0500, C M Reinehr wrote: > I can't say for sure whether it's i2o_block that's causing the problem, but I > have a dual-Opteron server that's running up-to-date Etch with md RAID-1. It > seems that about once a month or so when I check my logs I see that one of > the md devices has become corrupted and was rebuilt. For example: > > Jan 7 01:06:03 eljudnir kernel: block-osm: transfer error > Jan 7 01:06:14 eljudnir kernel: disk 0, wo:0, o:1, dev:i2o/hdc1 > Jan 7 01:06:14 eljudnir kernel: disk 1, wo:0, o:1, dev:i2o/hdd1 > Jan 7 01:06:18 eljudnir kernel: block-osm: transfer error > Jan 7 01:13:14 eljudnir mdadm: Rebuild20 event detected on md device /dev/md1 > ... > > But, I suppose this also could be the result of a disk drive that is failing > or any of several other causes. > > I'm using i2o_core & i2o_block. It's a Tyan S2882UG3NR Thunder K8S M/B with a > built-in Adaptec AIC7902W dual-channel U320 SCSI controller. mdadm runs a raid consistency check once a month, which will likely appear as a rebuild in the logs, although it is actually just a compare being done. So maybe that is what it is. Of course the transfer error seems to indicate it probably isn't. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpt_i2o and i2o_block on amd64 etch
C M Reinehr wrote: I don't know if the i2o_block issues were specifically with 64-bit, 32-bit or whatever. I was somewhat surprised to find that when I did searches for dpt_i2o and i2o_block and AMD64 last week, some of the top results were from my own thread here on installing on AMD64 two years ago! Kind of depressing. So: Anybody had recent problems with i2o_block in production on AMD64? I can't say for sure whether it's i2o_block that's causing the problem, but I have a dual-Opteron server that's running up-to-date Etch with md RAID-1. It seems that about once a month or so when I check my logs I see that one of the md devices has become corrupted and was rebuilt. For example: Jan 7 01:06:03 eljudnir kernel: block-osm: transfer error Jan 7 01:06:14 eljudnir kernel: disk 0, wo:0, o:1, dev:i2o/hdc1 Jan 7 01:06:14 eljudnir kernel: disk 1, wo:0, o:1, dev:i2o/hdd1 Jan 7 01:06:18 eljudnir kernel: block-osm: transfer error Jan 7 01:13:14 eljudnir mdadm: Rebuild20 event detected on md device /dev/md1 ... But, I suppose this also could be the result of a disk drive that is failing or any of several other causes. I'm using i2o_core & i2o_block. It's a Tyan S2882UG3NR Thunder K8S M/B with a built-in Adaptec AIC7902W dual-channel U320 SCSI controller. Thanks, that's useful. I will probably end up installing using the i2o_block (if that turns out to be possible) and then roll my own using dpt_i2o. Somehow using the "official" Adaptec driver feels better. I have no idea why it wasn't included as the "official" driver... it's been working flawlessly for me since mid-2005. Not one disk error (that I can see). By the way, how do other people detect RAID errors remotely on AMD64 and these i2o type cards? I seem to remember raidutils didn't work for some reason when I tried it two years ago. If it had worked, I would have been using it all this time. How do you know when a drive has failed, short of constantly grepping the syslog for errors (and I don't even really know what exactly to look for there)? I have often thought that the disk performance with the 2015S zero channel controller is not all that great, but I have no good handle on whether it's the hard drives (73 GB Fujitsu 10k) or the RAID controller itself, or something else (perhaps I've done something dumb with the kernel config, I'm really no expert). I'm thinking to replace the current drives with some 15k drives I can get through a friend of mine (he is able to get 146 GB 15k drives from Dell for about US$260 each). Does that sound like a good deal? Will I see any good improvement in performance with the 15k drives? This is a LAMP server with dual Opteron 265. I figure I can replace the drives the same time I upgrade the rest of the system and that should see me for the next year or two at least... Thanks again (sorry for all the questions!)... /Neil -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpt_i2o and i2o_block on amd64 etch
On Monday 14 May 2007 11:09, Neil Gunton wrote: > Lennart Sorensen wrote: > > On Mon, May 14, 2007 at 08:59:17AM -0500, Neil Gunton wrote: > >> I've never done that (at install time anyway) - are you talking about > >> just using something like modprobe or insmod? > > > > Yes using modprobe (insmod should almost never be used manually). > > > >> I always thought Adaptec was a pretty major company. I guess I was wrong > >> (or at least chose a card that turned out to be kind of a loser). I > >> thought that drivers were difficult back in 2005 because the card was so > >> new. Now it appears the opposite - nobody is using it because it just > >> never took off at all. > > > > I remember all the hype about i2o a long time ago, and I thought it had > > totally disappeared. I was rather surprised a couple of years ago when > > someone asked how to get i2o working with the amd64 sarge installer. > > > > Adaptec is a large company, but it seems a lot less low end users bother > > with scsi anymore. I think the main market is enterprise level with > > SAS today. Parallel shared single point of failure busses are > > fortunately going away now. > > I remember hearing anecdotal stories around 1-2 years ago about the > i2o_block driver causing sporadic disk corruption. Does anybody have any > insight on whether those problems were found and fixed? If the driver > never got enough use to give the developer enough info to debug it, then > perhaps I should install with i2o_block and then roll my own kernel > again with the dpt_i2o driver (Mark Salyzyn recently emailed me the most > recent version). I guess I'll have to read up again on rolling your own > kernel "the debian way", I seem to remember it was kind of convoluted... > > I don't know if the i2o_block issues were specifically with 64-bit, > 32-bit or whatever. I was somewhat surprised to find that when I did > searches for dpt_i2o and i2o_block and AMD64 last week, some of the top > results were from my own thread here on installing on AMD64 two years > ago! Kind of depressing. > > So: Anybody had recent problems with i2o_block in production on AMD64? > > Thanks again, > > /Neil I can't say for sure whether it's i2o_block that's causing the problem, but I have a dual-Opteron server that's running up-to-date Etch with md RAID-1. It seems that about once a month or so when I check my logs I see that one of the md devices has become corrupted and was rebuilt. For example: Jan 7 01:06:03 eljudnir kernel: block-osm: transfer error Jan 7 01:06:14 eljudnir kernel: disk 0, wo:0, o:1, dev:i2o/hdc1 Jan 7 01:06:14 eljudnir kernel: disk 1, wo:0, o:1, dev:i2o/hdd1 Jan 7 01:06:18 eljudnir kernel: block-osm: transfer error Jan 7 01:13:14 eljudnir mdadm: Rebuild20 event detected on md device /dev/md1 ... But, I suppose this also could be the result of a disk drive that is failing or any of several other causes. I'm using i2o_core & i2o_block. It's a Tyan S2882UG3NR Thunder K8S M/B with a built-in Adaptec AIC7902W dual-channel U320 SCSI controller. Cheers! cmr -- Debian 'Etch' - Registered Linux User #241964 "More laws, less justice." -- Marcus Tullius Ciceroca, 42 BC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpt_i2o and i2o_block on amd64 etch
Lennart Sorensen wrote: On Mon, May 14, 2007 at 08:59:17AM -0500, Neil Gunton wrote: I've never done that (at install time anyway) - are you talking about just using something like modprobe or insmod? Yes using modprobe (insmod should almost never be used manually). I always thought Adaptec was a pretty major company. I guess I was wrong (or at least chose a card that turned out to be kind of a loser). I thought that drivers were difficult back in 2005 because the card was so new. Now it appears the opposite - nobody is using it because it just never took off at all. I remember all the hype about i2o a long time ago, and I thought it had totally disappeared. I was rather surprised a couple of years ago when someone asked how to get i2o working with the amd64 sarge installer. Adaptec is a large company, but it seems a lot less low end users bother with scsi anymore. I think the main market is enterprise level with SAS today. Parallel shared single point of failure busses are fortunately going away now. I remember hearing anecdotal stories around 1-2 years ago about the i2o_block driver causing sporadic disk corruption. Does anybody have any insight on whether those problems were found and fixed? If the driver never got enough use to give the developer enough info to debug it, then perhaps I should install with i2o_block and then roll my own kernel again with the dpt_i2o driver (Mark Salyzyn recently emailed me the most recent version). I guess I'll have to read up again on rolling your own kernel "the debian way", I seem to remember it was kind of convoluted... I don't know if the i2o_block issues were specifically with 64-bit, 32-bit or whatever. I was somewhat surprised to find that when I did searches for dpt_i2o and i2o_block and AMD64 last week, some of the top results were from my own thread here on installing on AMD64 two years ago! Kind of depressing. So: Anybody had recent problems with i2o_block in production on AMD64? Thanks again, /Neil -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpt_i2o and i2o_block on amd64 etch
On Mon, May 14, 2007 at 08:59:17AM -0500, Neil Gunton wrote: > I've never done that (at install time anyway) - are you talking about > just using something like modprobe or insmod? Yes using modprobe (insmod should almost never be used manually). > I always thought Adaptec was a pretty major company. I guess I was wrong > (or at least chose a card that turned out to be kind of a loser). I > thought that drivers were difficult back in 2005 because the card was so > new. Now it appears the opposite - nobody is using it because it just > never took off at all. I remember all the hype about i2o a long time ago, and I thought it had totally disappeared. I was rather surprised a couple of years ago when someone asked how to get i2o working with the amd64 sarge installer. Adaptec is a large company, but it seems a lot less low end users bother with scsi anymore. I think the main market is enterprise level with SAS today. Parallel shared single point of failure busses are fortunately going away now. > Maybe next time I should go with one of those 3Ware SATA RAID cards. I > heard they are blowing the doors off anything else in terms of speed. > But I'm a little concerned about SATA drive reliability. Well my personal experience is that I have had less drive failures with SATA than with SCSI. So who knows. People with larger data sets or different brands will have different results. > Does anyone have a handle on if/why SCSI would be more reliable than > SATA? I remember reading that SCSI drives are built better, but SATA > seems so attractive pricewise these days that I'm wondering if I should > just go with that next time. How about speed with SATA vs SCSI - anybody > have practical experience of that? Well certainly the claim is that scsi drives are better built, although I think today the main feature of scsi drives is that you can get 15k rpm drives with faster seek times (well not counting the WD raptor drives which seem to be basically scsi style disks with SATA interface, at scsi prices). I think the main reason sata/pata drives are cheaper is simply volume for the most part. > If you still want tops in speed and reliability, is SCSI still the way > to go? It seems to be dying, except perhaps on the server. If you want fast random access, you go scsi. If you want pure sequential transfer rate, you go sata. The much higher density of the media on the large sata drives can not be matched by the higher rpm but much lower density of even the largest scsi drives. The fast rpm and low seek time is for random access and multiple simultanious accesses, but not for transfer rate. You generally can make up the transfer rate using striping or raid5/6 or similar. The idea seems to be that having smaller disks with faster access to any given sector using many disks and hence many heads, is faster than using a few large disks with less headers as a result. After all SAS drives seem to be going 2.5" to a large extent in order to fit even more disks with more heads in the same space. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpt_i2o and i2o_block on amd64 etch
Lennart Sorensen wrote: Well there has always been the option of going to the console on tty2 and telling it to load the driver, and going back to the installer on console 1 and continuing. I've never done that (at install time anyway) - are you talking about just using something like modprobe or insmod? I think the problem could be that most drivers are auto detected by pci id, which may not be easy to do for the I2O stuff. I don't actually know how i2o devices appear on the system. Of course there also aren't that many people using i2o, so it may just be that no one ever bothered to test the installer on such a system and complain about it not working so that it could have been fixed. After all if the installer developers don't know it doesn't work, they can't fix it. I always thought Adaptec was a pretty major company. I guess I was wrong (or at least chose a card that turned out to be kind of a loser). I thought that drivers were difficult back in 2005 because the card was so new. Now it appears the opposite - nobody is using it because it just never took off at all. Maybe next time I should go with one of those 3Ware SATA RAID cards. I heard they are blowing the doors off anything else in terms of speed. But I'm a little concerned about SATA drive reliability. Does anyone have a handle on if/why SCSI would be more reliable than SATA? I remember reading that SCSI drives are built better, but SATA seems so attractive pricewise these days that I'm wondering if I should just go with that next time. How about speed with SATA vs SCSI - anybody have practical experience of that? If you still want tops in speed and reliability, is SCSI still the way to go? It seems to be dying, except perhaps on the server. Thanks again, /Neil -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpt_i2o and i2o_block on amd64 etch
On Fri, May 11, 2007 at 04:26:13PM -0500, Neil Gunton wrote: > Thanks very much, that's reassuring. I still have a tiny doubt, however, > since I remember CentOS x86_64 did not recognize the disks at first, but > then gave you an option during the install to manually select a driver, > which fortunately included i2o_block. Debian, as I recall, never had > such an option. > > So, obviously, it was possible for the kernel to have the module be > available, but not automatically recognized as "the" module to use. Pretty much, but I think on sarge at least, the amd64 version did not even have the module compiled, so there was no way to get it to work. At least Etch appears to have it enabled so at least it is possible to load it manually. > Can we be fairly certain that Etch will actually recognize these disks > automatically, or is it possible that the driver would be in the same > state as the old CentOS - present, but somehow not automatic? And if > that happened, is there a way now for me to tell Debian to use it during > the boot? Well there has always been the option of going to the console on tty2 and telling it to load the driver, and going back to the installer on console 1 and continuing. > Sorry if this is a dumb question, it's just I am so used to weird things > that take me by surprise... don't want this road trip to be another > epic experience. Well certainly expert mode install asks many more questions. And there is always console 2 where you can manually load a module. I think the problem could be that most drivers are auto detected by pci id, which may not be easy to do for the I2O stuff. I don't actually know how i2o devices appear on the system. Of course there also aren't that many people using i2o, so it may just be that no one ever bothered to test the installer on such a system and complain about it not working so that it could have been fixed. After all if the installer developers don't know it doesn't work, they can't fix it. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
