Re: Encrypted virtual disk.
man i love your optimism On Sun, Aug 02, 2009 at 09:35:58PM +, 4625 wrote: > On Sun, 2 Aug 2009, James wrote: > We call that luck and a very good UPS. >>> I call that good driver, without UPS. >> Seems definitely to be luck, good driver or not. No 'good driver' >> will completely mitigate the damage a power|other failure during a >> write on an encrypted disk would do. It is also probably a > > I write on encrypted disk not 24h/7. So, if power failure occur at idle > time, file system will be clean. :-) > >> documentation bug if the vncrypt man page doesn't mention this >> possibility. > > P.S. Folks, how long salt key could be? > > -- > 4625
Re: random crashes on a firewall with OpenBSD 4.5-stable
ropers wrote: > 2009/6/26 Jussi Peltola : >> memtest86+: it can prove it's broken, but if it doesn't >> find problems it doesn't guarantee there are none. This is correct. > I've said this before, but I've yet to see faulty RAM whose problems > memtest86+ will not detect during a 24hr burn-in test. Sure, I've seen > faulty RAM that memtest86+ said was ok during a single-pass test, but > if you let memtest86+ run for 24 hours it'll probably find just about > any error. > > Of course, depending on your circumstances it may be more economical > to just chuck the suspect RAM instead of wasting 24 hours. And > granted, YMMV. But if anyone has ever seen any faulty RAM whose > problems a 24hr burn-in test with memtest86+ could not detect, I'd be > very interested in hearing that. How about this... Some years ago, Walmart had some Athlon-based "$200 PCs", they used SDRAM, 100MHz, IIRC. For giggles one day, I stuck some oddball SDRAM modules in one of them, and not too surprisingly, the thing failed to boot. In addition to being blatantly the wrong speed (66MHz), it was some really odd junk that didn't work in much of anything that used normal SDRAM of any speed. I didn't expect it to work, it confirmed my expectations; any OS that was loaded on the disk refused to boot very far before barfing all over itself with this RAM installed. Having enjoyed that part (yeah, I'm oddly amused), I figured running memtest86 would be an interesting test. Well, I'm somewhat disturbed to say that memtest86 had no problem "testing" all that junk^Woddball RAM, and told me it was all perfect. It may have been..but it certainly didn't work in that machine, and yet, it passed every diagnostic memtest86 threw at it for hours. I don't recall how long I left it cooking, but I know it was more than 24 hours, and I think it was for a few days before I needed that bit of shelf space and shut down the test. You can argue that memtest86 was correct that the memory itself was good, but since no other OS seemed to be able to make that RAM work in that machine, I don't think it is a very convincing argument -- that machine's memory subsystem was clearly broke, the diagnosis easy to confirm (swap RAM, system works, swap back, system won't boot). Yes, I think this qualifies as a memtest86 bug, as it missed something very basic, and maybe it's been fixed by now, but it still proves the point: passing diagnostics only means the diagnostics didn't find anything, it doesn't mean things are good. (years before that, I saw a great demonstration warning of this: one of the machines I sold and support had a very good internal diagnostic that included a looping RAM test, BUT if you installed the DIP (the old, traditional IC style RAM) with pin 1 not properly plugged into the socket, the system would pass the internal diagnostics very well as long as you wished to run them. You see, this machine's diagnostics tested RAM in 64k pages. Pin #1 on a 256kbit RAM chip happened to be used to pick which of the four(1) 64k pages were selected on the RAM chip, so the diagnostics happened to just test the same 64k bits of that chip four times, and said, "no problems found", even though the OS or apps would crash rather soon after booting. Fortunately, my then young eyes were good enough to spot the pin bent under the socket.) memtest86 is a very impressive memory diagnostic program, it does good things and does them well, but passing memtest86, as with any diagnostic, just means "no problem FOUND". Nick. (1) those thinking, "hey, one pin can't select more than TWO pages of RAM" need not try to correct me, I'm right, you don't understand how this stuff works. :) Hint: the chips had only 16 pins, including power, data, address, ground...and yet had an org of 256k X 1bit)
Re: wpi and firmware error
On Sun, Aug 02, 2009 at 09:03:37PM -0400, Luis Useche wrote: > From time to time my network card stop working and a error message appears: > > wpi0: fatal firmware error I've been experiencing the same problem for about a year--ever since my university installed new access points. The old access points worked fine with wpi, but the new access points cause frequent firmware errors. Some days I just give up on wireless and connect an ethernet cable...
wpi and firmware error
Hello, >From time to time my network card stop working and a error message appears: wpi0: fatal firmware error firmware error log (count=1): error type = "SYSASSERT" (0x0005) error data = 0x0074 branch link = 0x08B60274 interrupt link = 0x03203560 time= 3916204702 driver status: tx ring 0: qid=0 cur=19 queued=0 tx ring 1: qid=1 cur=0 queued=0 tx ring 2: qid=2 cur=0 queued=0 tx ring 3: qid=3 cur=0 queued=0 tx ring 4: qid=4 cur=19 queued=0 tx ring 5: qid=5 cur=0 queued=0 rx ring: cur=6 802.11 state 4 The network start working again when I call dhclient. Since I could have my network back again pretty quickly is not a critical issue. However, having the problem is annoying. I am using wpi-firmware-3.2.tgz Does any one else have this problem? Best, Luis Useche use...@gmail.com
Re: Long time to connect to MySQL server on sparc64
On Sun, Aug 02, 2009 at 11:18:38PM +0200, MPrik wrote: > Hi, > I have problem with connection to MySQL server running on Sun Netra X1. > Connecting to MySQL server takes average around 20 second, but it's > variable. After connect to the server, SQL queries are fast. Problem is > only with connection and it doesn't matter if I connecting through mysql > socket, localhost or client from LAN. The delay is same. I don't know > what is wrong, but it's very annoying and makes web pages which uses DB > very slow. The MySQL server is from package mysql-server-5.0.51a.tgz with > common my.cnf (sample my-small.cnf) configuration and running on OpenBSD > 4.3 GENERIC#1555 sparc64. I tried compile MySQL 4.1.22 from source but > problem is same. There's propably something wrong only with sparc64 > distribution because I have same configuration on OpenBSD 4.3 GENERIC#698 > i386 and without this problem. > After some attempts to find a solution to the problem I found technique > which make connection faster, but I don't know what that implies. If I > connect to the MySQL and at the same time execute something on server > into which I connecting, the connection accomplish immediately. If I > execute infinity loop like this "while true; do uptime; done;" connection > to MySQL afterwards isn't longer than 1 second. > > Can anybody help me how fix this problem? Check your mysql logs. There may be a clue there. How is DNS on this machine? Does it resolve the machines trying to connect to it? -- Darrin Chandler| Phoenix BSD User Group | MetaBUG dwchand...@stilyagin.com | http://phxbug.org/ | http://metabug.org/ http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation
Re: F1-F10, 'HOME', 'END' keys.
On Sat, 1 Aug 2009, Richard Toohey wrote: 'HOME' and 'END' keys will display the '~' almost everywhere in OpenBSD console. openbsd home key tilde First link might help with the HOME and END keys; depending on what exactly you are doing. Maybe for ksh it would work, I don't know. First of all there is impropriety bind format: 'bind '^[[3'=prefix-2'. Bash advice to use the ':' instead of '='. Bash does not know 'prefix-2'. I have different scancode on HOME and END keys - ^[[7~, ^[[8~. -- 4625
Long time to connect to MySQL server on sparc64
Hi, I have problem with connection to MySQL server running on Sun Netra X1. Connecting to MySQL server takes average around 20 second, but it's variable. After connect to the server, SQL queries are fast. Problem is only with connection and it doesn't matter if I connecting through mysql socket, localhost or client from LAN. The delay is same. I don't know what is wrong, but it's very annoying and makes web pages which uses DB very slow. The MySQL server is from package mysql-server-5.0.51a.tgz with common my.cnf (sample my-small.cnf) configuration and running on OpenBSD 4.3 GENERIC#1555 sparc64. I tried compile MySQL 4.1.22 from source but problem is same. There's propably something wrong only with sparc64 distribution because I have same configuration on OpenBSD 4.3 GENERIC#698 i386 and without this problem. After some attempts to find a solution to the problem I found technique which make connection faster, but I don't know what that implies. If I connect to the MySQL and at the same time execute something on server into which I connecting, the connection accomplish immediately. If I execute infinity loop like this "while true; do uptime; done;" connection to MySQL afterwards isn't longer than 1 second. Can anybody help me how fix this problem?
Re: Encrypted virtual disk.
On Sun, Aug 2, 2009 at 5:35 PM, 4625<4625...@gmail.com> wrote: > P.S. Folks, how long salt key could be? 128 bytes.
Re: complete restore using NFS
On 8/2/09 12:11 PM, Nick Bender wrote: >> How to reach that server when in shell mode? Or is there another way to >> do this? > > NFS isn't available on the install media, and neither is ssh. If the > server has ftp or > http then you can use ftp like: > > ftp -o - http://someserver/part.dump | restore ... Thanks, this worked fine. This method does require one possible change from the FAQ: http://www.openbsd.org/faq/faq14.html#Backup After restoring root and rebooting into single-user mode to restore the other partitions, ftp isn't available since we haven't yet restored /usr. Options are either to restore all partitions from the shell with ftp, or reboot into single-user mode and use some other means to restore the other partitions. I did the latter, using NFS. Thanks again. dn
Re: Encrypted virtual disk.
On Sun, 2 Aug 2009, James wrote: We call that luck and a very good UPS. I call that good driver, without UPS. Seems definitely to be luck, good driver or not. No 'good driver' will completely mitigate the damage a power|other failure during a write on an encrypted disk would do. It is also probably a I write on encrypted disk not 24h/7. So, if power failure occur at idle time, file system will be clean. :-) documentation bug if the vncrypt man page doesn't mention this possibility. P.S. Folks, how long salt key could be? -- 4625
Simplest and safest way to activate external mail transfert
What would be the simplest and safest way in order to give php the possibility to transfert mails via the php mail command ? I started to look out after postfix install or sendmail configuration, however since i'm not used to both methods please can you indicate me a suggest ? Thanks
Re: complete restore using NFS
> How to reach that server when in shell mode? Or is there another way to > do this? NFS isn't available on the install media, and neither is ssh. If the server has ftp or http then you can use ftp like: ftp -o - http://someserver/part.dump | restore ... -N
complete restore using NFS
How to restore entire partitions using NFS? When booting the install disk into the shell and bringing up a network interface, an NFS mount command returns an error: # mkdir /store # mount -t nfs -o rw 10.41.2.3:/store /store mount: no mount helper program found for nfs: No such file or directory I am attempting to do a complete restore of all partitions following the dump/restore procedure in the FAQ, but using NFS instead of tape: http://www.openbsd.org/faq/faq14.html#Backup The fdisk, disklabel and newfs commands all worked OK, but getting to the dump images, available on an NFS server, is a problem. How to reach that server when in shell mode? Or is there another way to do this? thanks dn
Il punto della settimana
[IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] 01.08.2009 [IMAGE] Gentile Cliente le proponiamo il nostro aggiornamento settimanale sui mercati finanziari, a cura del Servizio Studi Intesa Sanpaolo. SI RIDUCE LA CONTRAZIONE ATTESA DEL PIL AMERICANO.. Dopo una caduta del 5,5% nel 10 trimestre 2009, lattivit` economica negli Stati Uniti h attesa in contrazione dell1,5% nel 20 trimestre (la prima stima del PIL h in uscita il 31 luglio). Sebbene si tratti ancora di una variazione negativa che conferma che la recessione negli Stati Uniti h proseguita nel secondo trimestre, la riduzione della discesa, associata allevidenza di segnali incoraggianti gi` per il trimestre successivo, rendono il quadro economico americano tutto sommato favorevole, soprattutto se letto alla luce delle previsioni fosche di appena sei mesi fa. Resta una previsione di crescita modesta e probabilmente limitata dallonere dellindebitamento pubblico crescente dello Stato americano. Il miglioramento della congiuntura americana, sebbene non ancora chiaramente visibile n! el mercato del lavoro e nei dati sulla produzione, h evidente dai sondaggi, dagli ordinativi e dalle indicazioni di recupero nel mercato immobiliare, aprendo la strada anche a possibili revisioni delle stime di crescita per il 2010. Gli altri approfondimenti: * I dati macro della settimana, in Italia e all'estero. * La settimana passata: azioni, tassi, valute e commodities. * Gli appuntamenti della settimana. [IMAGE] SCARICA IL DOCUMENTO .PDF [IMAGE] [IMAGE] A cura del Servizio Studi di Intesa Sanpaolo Con Superflash telefonare ti costa meno. Se acquisti SuperFlash e attivi entro 30 giorni una SIM Nrverca, puoi beneficiare di una tariffa speciale per 6 mesi dall'attivazione. Promozione valida fino al 31.12.2009. [IMAGE] SCOPRI LA PROMOZIONE>> [IMAGE] Messaggio Pubblicitario con finalit` promozionale. Per le condizioni economiche e contrattuali fare riferimento ai Fogli Informativi, disponibili anche presso le filiali della Banca. [IMAGE] [IMAGE] Mutui Prestiti Conti e Libretti Check-up finanziario Servizi via Internet Carte Risparmio Trading Previdenza Riceve questa email perchi si h iscritto a una delle newsletter dedicate ai clienti dei nostri Servizi via internet, telefono e cellulare. Pur aggiornare in ogni momento il suo profilo e modificare la sua iscrizione attraverso i suoi Servizi via internet. [IMAGE] ) BANCA INTESA SANPAOLO 2007 Assistenza Servizi via internet 800.773.322 - Informazioni su prodotti e servizi 800.303.306.
bwi slow start
Hi, I have a Dell Latitude D610 laptop that has a bwi wireless interface. I can successfully connect to a 802.11g netgear router. I use the following commands to bring it up: #!/bin/sh ifconfig bwi0 nwid nwkey persist:0x ifconfig bwi0 up dhclient bwi0 ping -c 10 www.google.com However, after it is up, the network first comes up for about 10-30 seconds, in that time, all ping works fine. Then, the network stops working, I cannot even ping my AP. It stuck in this state for about 1 or 2 minutes, then everything works fine again. Does anyone know what is wrong? Thanks, Jingshao Chen
Re: Encrypted virtual disk.
> > We call that luck and a very good UPS. > I call that good driver, without UPS. Seems definitely to be luck, good driver or not. No 'good driver' will completely mitigate the damage a power|other failure during a write on an encrypted disk would do. It is also probably a documentation bug if the vncrypt man page doesn't mention this possibility.
help with trunk link failover (only the failover nic works)
I run 4.5 -release on a Thinkpad x200, and I would like to have trunk0 working. The problem is it works, that is it switches the nics (one ethernet and one wireless, as per manpage example), but the ethernet nic does not work. I've also tried to boot with the cable inserted, and it does not communicate with the outside, but as soon as I unplug the cable, the wireless starts working, and if I plug the cable in again, again it hangs there. Of course if I use only ethernet, no problem. Here are my settings: $ cat hostname.em0 up $ cat hostname.iwn0 up chan 6 nwid mylan wpa wpapsk mykey $ cat hostname.trunk0 trunkproto failover trunkport em0 trunkport iwn0 192.168.1.102 netmask 255.255.255.0 ifconfig wireless: $ ifconfig lo0: flags=8049 mtu 33204 priority: 0 groups: lo inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 em0: flags=8943 mtu 1500 lladdr macaddress priority: 0 trunk: trunkdev trunk0 media: Ethernet autoselect (none) status: no carrier inet6 fe80::21f:16ff:fe1f:dae3%em0 prefixlen 64 scopeid 0x1 iwn0: flags=8943 mtu 1500 lladdr macaddress priority: 0 trunk: trunkdev trunk0 groups: wlan media: IEEE802.11 autoselect (OFDM12 mode 11g) status: active ieee80211: nwid mylan chan 6 bssid macaddress 240dB wpapsk displayed> wpaprotos wpa1,wpa2 wpaakms psk wpaciphers tkip,ccmp wpagroupcipher tkip inet6 fe80::222:faff:fef5:62fa%iwn0 prefixlen 64 scopeid 0x2 enc0: flags=0<> mtu 1536 priority: 0 trunk0: flags=8843 mtu 1500 lladdr macaddress priority: 0 trunk: trunkproto failover trunkport iwn0 active trunkport em0 master groups: trunk egress media: Ethernet autoselect status: active inet 192.168.1.102 netmask 0xff00 broadcast 192.168.1.255 inet6 fe80::21f:16ff:fe1f:dae3%trunk0 prefixlen 64 scopeid 0x5 pflog0: flags=141 mtu 33204 priority: 0 groups: pflo $ ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1): 56 data bytes 64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=1.159 ms 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=5.205 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.170 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=1.157 ms ifconfig eternet cable plugged in: $ ifconfig lo0: flags=8049 mtu 33204 priority: 0 groups: lo inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 em0: flags=8943 mtu 1500 lladdr macaddress priority: 0 trunk: trunkdev trunk0 media: Ethernet autoselect (100baseTX full-duplex) status: active inet6 fe80::21f:16ff:fe1f:dae3%em0 prefixlen 64 scopeid 0x1 iwn0: flags=8943 mtu 1500 lladdr macaddress priority: 0 trunk: trunkdev trunk0 groups: wlan media: IEEE802.11 autoselect (OFDM18 mode 11g) status: active ieee80211: nwid mylan chan 6 bssid macaddress 240dB wpapsk displayed> wpaprotos wpa1,wpa2 wpaakms psk wpaciphers tkip,ccmp wpagroupcipher tkip inet6 fe80::222:faff:fef5:62fa%iwn0 prefixlen 64 scopeid 0x2 enc0: flags=0<> mtu 1536 priority: 0 trunk0: flags=8843 mtu 1500 lladdr macaddress priority: 0 trunk: trunkproto failover trunkport iwn0 trunkport em0 master,active groups: trunk egress media: Ethernet autoselect status: active inet 192.168.1.102 netmask 0xff00 broadcast 192.168.1.255 inet6 fe80::21f:16ff:fe1f:dae3%trunk0 prefixlen 64 scopeid 0x5 pflog0: flags=141 mtu 33204 priority: 0 groups: pflog $ ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1): 56 data bytes $ ping -v -c 1 -w 1 192.168.1.1 PING 192.168.1.1 (192.168.1.1): 56 data bytes --- 192.168.1.1 ping statistics --- 1 packets transmitted, 0 packets received, 100.0% packet loss Any ideas?
Re: Question about spamd
On 2009-07-31, Chris Bennett wrote: > So, normal spam - temp rejection, goes away. > Good email - temp rejection, keeps trying till successful and is > whitelisted. > Extra bad spam - temp rejection, keeps trying till successful and is > whitelisted. > > Please correct me if I am wrong. Good emails and extra bad spam have > equal chance of getting through? You missed half of what greylisting is for - even if a spam-sender is doing normal retries rather than one-shot delivery attempts, mail from unknown senders is delayed long enough that it increases the chance a spam-sender is picked up by some other mechanism (spamtraps, blacklists etc).
Re: random crashes on a firewall with OpenBSD 4.5-stable
On Sun, Aug 2, 2009 at 10:45 AM, ropers wrote: > Of course, depending on your circumstances it may be more economical > to just chuck the suspect RAM instead of wasting 24 hours. And > granted, YMMV. But if anyone has ever seen any faulty RAM whose > problems a 24hr burn-in test with memtest86+ could not detect, I'd be > very interested in hearing that. > > regards, > --ropers > > I have seen errors appear after more than 24 hours: 36 or 48 hours. Yes, it can happen. Cheers, -- Mattieu Baptiste "/earth is 102% full ... please delete anyone you can."
Re: random crashes on a firewall with OpenBSD 4.5-stable
2009/6/26 Jussi Peltola : > memtest86+: it can prove it's broken, but if it doesn't > find problems it doesn't guarantee there are none. I've said this before, but I've yet to see faulty RAM whose problems memtest86+ will not detect during a 24hr burn-in test. Sure, I've seen faulty RAM that memtest86+ said was ok during a single-pass test, but if you let memtest86+ run for 24 hours it'll probably find just about any error. Of course, depending on your circumstances it may be more economical to just chuck the suspect RAM instead of wasting 24 hours. And granted, YMMV. But if anyone has ever seen any faulty RAM whose problems a 24hr burn-in test with memtest86+ could not detect, I'd be very interested in hearing that. regards, --ropers