Re: spammers getting less stupid?
>> I see it too. I also use greyscanner to catch spammers and I see >> a lot of spam to @mydomains. So I trap >> all hosts sending to addresses with numbers in them (as I don't >> have any legit accounts with numbers). This catches almost all spam. I finally got to deploying greyscanner on my mailservers, and did something similar: trap every recipient address with two or more digits in the user part (one digit could be a typo, say a '2' before the '@'). This catches most of it. >> I make all the ficticious addresses into spam traps. >> Here's a bit of the output from my spamd database: >> SPAMTRAP|a3d2...@witworx.com >> SPAMTRAP|a7c85e...@witworx.com >> ... I do the same, but it seems less relevant now. In the past, when I published a trap address, the bots harvested it and tried to send to it, getting themselves trapped; but now they just shoot out to wh4t3v3rg4rb...@mydomain.org, apparently generating the user part themselves (as opposed to harvesting real/trap addresses somewhere). > I clean out the traps every few days with a script and back they come > with new tries. Yes. Recently, the 64.18.0.0 farm has been active on me. $ spamdb | grep TRAPPED TRAPPED|86.122.194.113|1356282022 TRAPPED|212.110.189.85|1356283885 TRAPPED|216.106.48.217|1356289572 TRAPPED|64.18.0.21|1356308593 TRAPPED|171.76.91.71|1356281598 TRAPPED|64.18.0.140|1356286482 TRAPPED|217.200.184.87|1356290678 TRAPPED|64.18.0.23|1356304740 TRAPPED|64.18.0.142|1356285089 TRAPPED|194.228.32.128|1356286433 TRAPPED|64.18.0.25|1356298962 TRAPPED|64.18.3.31|1356302574 TRAPPED|64.18.0.177|1356322196 TRAPPED|91.121.102.20|1356281598 TRAPPED|178.236.112.75|1356281598 TRAPPED|64.18.0.187|1356301851 TRAPPED|64.18.0.144|1356295832 TRAPPED|67.228.3.116|1356298119 TRAPPED|64.18.0.27|1356310158 TRAPPED|64.18.0.181|1356286964 TRAPPED|217.72.102.116|1356281598 TRAPPED|64.20.227.133|1356282002 TRAPPED|64.18.0.146|1356305342 TRAPPED|64.18.0.183|1356294508 TRAPPED|213.174.32.135|1356281598 TRAPPED|89.189.37.102|1356286482 TRAPPED|64.18.0.148|1356290415 TRAPPED|64.18.0.247|1356293785 TRAPPED|64.18.0.185|1356286052 TRAPPED|74.125.149.196|1356287445 _All_ of the 64.18.0.0 hosts are trying dd02...@stare.cz for two days now ... > @GOOD = ( > qr'^[A-Za-z\.\+]+@mydomain.(com|se)$'i, > ); > $COMPREHENSIVE = 1; I was trying this too, until a customer made a typo, blocking his company's smtp server. On Nov 05 22:36:30, s...@spacehopper.org wrote: > On 2012-11-01, Jan Stary wrote: > > Anyway, it seems (some) spambots got less demented and actually do > > resend, getting themselves whitelisted - thus working themselves > > around the whole premise of greylisting. > > Not the whole premise... A good part of it is to just delay the mail, > this increases the chance that spamtraps etc will have picked up the > mail before you accept it, thus increasing the effectiveness of other > checks (DNSBL, razor/pyzor, etc). True. Greyscanner has helped me very much! Jan
Re: openbsd clusters
:) A good one! Nice writing, Nick. My favorite: > 'course, most people are not thinking about the long-term health of the > company, but the short-term "what can I stuff on my resume on my way out > the door before this blows up" //mxb On 23 dec 2012, at 04:43, Nick Holland wrote: > On 12/22/12 07:54, Friedrich Locke wrote: > ... >> But for other services i don't have now what i could use. A example: i need >> a file system that must expand by adding more machine in the network in a >> simple way. > > in plain English: "I'm not thinking out the design carefully, so I'm > going to rely on fancy shit to haul my ass out of the fire when the > predictable (and not so predictable) happens. > > You don't need that for your problem, you need that for the solution you > came up with for your problem. Your solution is wrong. > > You know your needs will change in the future, so build the whole system > around the idea of modular storage and other scalability design features > -- not "unlimited expandable storage". > > Chunk your data from the very beginning. In the case of a mail server, > part of the user's LDAP record indicates the storage unit where it is > stored. > > Yes, this is a better design. > > I've seen many designs where the answer was "toss it all in one pool, > let some 'advanced technology' keep my ass out of the fire." They have > all been total shit. Usual result: the "advanced technology" gathers > the kindling, splits the logs, lights the fire, and tosses your ass on > the pyre before you ever get around to the first "expansion". If you > wish to argue that your "problem" is special, and requires One Big Pool > of Storage, feel free to tell me about it (off list), maybe someone's > got one. More likely, you will be telling me about your SOLUTION which > requires one big pool, not the root problem. (I'm not above learning > new stuff, but I'm done with assuming most people know something I don't > -- that's something that is really annoying to be wrong about, I'm finding). > > Your design should incorporate (among other things): > * initial load handling. > * future load handling improvements. > * future storage upgrade. > * future storage REPLACEMENTS (you want to remove your three year old > storage module in favor of a new one ten times the size, but your six > month old one is still quite good) > * future complete solution replacements. (*) > the simplest possible solutions that will accomplish the above within > acceptable business frameworks (i.e., not "we'll have our entire IT > staff working a major multi-day holiday because that's the only way we > can accomplish this") > > Nick. > > > (*) if you ever wish to keep a closed source solution OUT of your > operations, this is your magic weapon to use with responsible, thinking > people. Every closed source solution is built around the idea of > keeping you a captive customer. But the fact is, if your business is > run well, in 50 years, it can still be around. You will almost > certainly have to replace entire systems with competing products "some > day" -- your company's success should not be dependent upon a third > party remaining in business. So, an exit strategy has to be part of any > good system design (even though it almost never is). How are you going > to scrape your legacy data off your old system and install it into its > replacement? When the APIs are proprietary, you won't... Ask your > prospective vendor "If you go bankrupt or otherwise leave the business > next year, how will we move >OUR< data stored in your system to another > product?" They will start with "We aren't going anywhere", which you > know they would say if they weren't sure about getting their paychecks > next week. > > 'course, most people are not thinking about the long-term health of the > company, but the short-term "what can I stuff on my resume on my way out > the door before this blows up"
Re: nfs 4
At one time there was: http://mailman.theapt.org/pipermail/openbsd-nfsv4/2007-January/88.html 2012/12/23 Philip Guenther : > On Sat, Dec 22, 2012 at 4:57 PM, Friedrich Locke > wrote: >> Does OBSD support NFS 4 ? If not, is there plans to do so ? > > It does not currently. I don't think anyone is working on it. > > Philip Guenther > -- May the most significant bit of your life be positive.
iwi0 behaviour change in snapshot
Hello, I'm running a snapshot right now and I get some strange error on iwi0 wireless interface. This device worked fine before, I think some 6 month old snapshot. I use it in a WPA2 protected wireless network. Here is what I get: iwi0: unknown authentification state 1 This is over and over, no matter what configuration I use, either fixed IP or DHCP. The machine is an IBM thinkpad T43, well known dmesg. The only message on lists is from 2007. Any semnificative changes currently? Thanks.
Re: iwi0 behaviour change in snapshot
> Hello, > I'm running a snapshot right now and I get some strange error on iwi0 > wireless interface. This device worked fine before, I think some 6 > month old snapshot. > I use it in a WPA2 protected wireless network. > Here is what I get: > iwi0: unknown authentification state 1 > This is over and over, no matter what configuration I use, either > fixed IP or DHCP. The machine is an IBM thinkpad T43, well known > dmesg. > The only message on lists is from 2007. Any semnificative changes currently? > Thanks. Disregard that please, I did all again from the man and it is up again. Excuse me for the wrong email, please, it was all at my side. Thank you.
Re: Netflow server software suggestion
Theron ZORBAS writes: > I want to use pflow interface. This part is very clear; thanks to > OpenBSD team. At application side i could not decide what port to > use. Can you help me with that? I look for a netflow server software > which has ability to work with mysql(or sqlite) database. I'd say $ pkg_add nfsen will get you the best of breed. Reading the package message will get you up and running pretty much right away. The web interface is flexible enough that it's helped me accurately track down sources of disruption when I needed to, and if you need more refined criteria, the query string you generate by point and click is displayed so you get a useful starting point. (I've been meaning to write a netflow/pflow/nfsen article for a while, but real life including a few incidents where nfsen came in handy have kept interfering). - P -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: External USB microphone
On 2012-12-22, Beni wrote: > ehci0: Error opening low/full speed isoc endpoint. > A low/full speed device is attached to a USB2 hub, and transaction > translations are not yet supported. > Reattach the device to the root hub instead. > uaudio_chan_open: error creating pipe: err=INVAL endpt=0x01 > > My microphone is attached to the root hub of the machine, so I don't > really get what's this all about. Try all the USB ports to make sure, and look for BIOS options to disable USB2 / EHCI, but it's fairly likely that if it's a modern machine you're out of luck without code to support transaction translations being written.
Re: directory monitoring
On 2012-12-22, Martijn van Duren wrote: > Hello misc, > > I recently compiled minidlna to run on my local OBSD based home server. > It runs great by default, but it relies upon inotify to receive > information on filesystem changes. > I really like the program, but it's a nuisance to rescan my multimedia > directories every time I add a new file, so I made an attempt at > implementing kqueue. Compared to inotify I run into two different > problems with kqueue. > 1) It is based upon open file descriptors, so I can't include every > directory I have in my multimedia-collection, because I run out of open > file descriptors. > 2) It only shows that there has been a change in the directory, so I > have to do a full compare of the files in the directory compared to the > entries in the database. > > Both aren't really big problems (the second is merely a nuisance and the > first one can be, albeit somewhat incomplete, worked around by just > including the most current directories). But I would really like to know > if there is alternative API in OpenBSD (and preferably even more > portable then that) that comes closer to Linux' inotify functionality, > or do I just have to make do with kqueue? > > Sincerely, > > Martijn van Duren > > I don't think there's an alternative; it may be worth taking a look at glib's gio-kqueue backend (used in devel/glib2 port; the patch is at http://distfiles.bsdfrog.org/glib-gio-kqueue-2.34.2-v2.patch) as used by gnome-tracker.
Re: vfs.nfs.iothreads
On Fri, Dec 21, 2012 at 02:34:50PM +0100, Jan Stary wrote: > On 5.2/i386, man sysctl says > > To adjust the number of kernel nfsio threads used to service asynchronous > I/O requests on an NFS client machine: > > # sysctl vfs.nfs.iothreads=4 > > The default is 4; 20 is the maximum. See nfssvc(2) and nfsd(8) for > further discussion. > > Does it still apply? The default now seems to be > > # sysctl vfs.nfs.iothreads > vfs.nfs.iothreads=-1 > > which scales itself to 4 when I copy a file from a NFS server. > Should I be touching vfs.nfs.iothreads manually? > Setting it to 20 just panicked my 5.2/i386. > > Also, neither nfssvc(2) nor nfsd(8) seems > to contain any "further discussion" of this. > ok, my proposal below. anyone want to ok it? jmc Index: lib/libc/gen/sysctl.3 === RCS file: /cvs/src/lib/libc/gen/sysctl.3,v retrieving revision 1.215 diff -u -r1.215 sysctl.3 --- lib/libc/gen/sysctl.3 18 Aug 2012 15:40:30 - 1.215 +++ lib/libc/gen/sysctl.3 23 Dec 2012 16:58:45 - @@ -2125,6 +2125,9 @@ Should be set high enough for the server to handle the maximum level of concurrency from its clients, typically four to six. +The default is set to 4 automatically when +.Xr nfsd 8 +is processing requests; 20 is the maximum it can be set to. .El .El .El Index: sbin/sysctl/sysctl.8 === RCS file: /cvs/src/sbin/sysctl/sysctl.8,v retrieving revision 1.164 diff -u -r1.164 sysctl.8 --- sbin/sysctl/sysctl.810 Apr 2012 15:57:36 - 1.164 +++ sbin/sysctl/sysctl.823 Dec 2012 16:58:45 - @@ -509,19 +509,6 @@ # sysctl net.inet.tcp.baddynamic=-871 .Ed .Pp -To adjust the number of kernel nfsio -threads used to service asynchronous -I/O requests on an NFS client machine: -.Pp -.Dl # sysctl vfs.nfs.iothreads=4 -.Pp -The default is 4; 20 is the maximum. -See -.Xr nfssvc 2 -and -.Xr nfsd 8 -for further discussion. -.Pp To set the amount of shared memory available in the system and the maximum number of shared memory segments: .Bd -literal -offset indent Index: sbin/nfsd/nfsd.8 === RCS file: /cvs/src/sbin/nfsd/nfsd.8,v retrieving revision 1.17 diff -u -r1.17 nfsd.8 --- sbin/nfsd/nfsd.83 Sep 2010 10:08:22 - 1.17 +++ sbin/nfsd/nfsd.823 Dec 2012 16:58:45 - @@ -91,6 +91,11 @@ A server should run enough daemons to handle the maximum level of concurrency from its clients, typically four to six. +The value can be altered using the +.Fl n +option, or the +.Va vfs.nfs.iothreads +.Xr sysctl 8 . .Pp .Nm listens for service requests at the port indicated in the
Re: vfs.nfs.iothreads
On Dec 21 19:01:44, j...@kerhand.co.uk wrote: > On Fri, Dec 21, 2012 at 02:34:50PM +0100, Jan Stary wrote: > > On 5.2/i386, man sysctl says > > > > To adjust the number of kernel nfsio threads used to service > > asynchronous > > I/O requests on an NFS client machine: > > > ># sysctl vfs.nfs.iothreads=4 > > > > The default is 4; 20 is the maximum. See nfssvc(2) and nfsd(8) for > > further discussion. > > > > Does it still apply? The default now seems to be > > > ># sysctl vfs.nfs.iothreads > >vfs.nfs.iothreads=-1 > > > > which scales itself to 4 when I copy a file from a NFS server. > > Should I be touching vfs.nfs.iothreads manually? > > Setting it to 20 just panicked my 5.2/i386. > > > > Also, neither nfssvc(2) nor nfsd(8) seems > > to contain any "further discussion" of this. > > > > i get -1 here too. but you;re saying that the value changes to 4 when > transferring, right? Yes, on the _client_ (sorry, I should have been explicit). What got me trying it is that sysctl(8) says To adjust the number of kernel nfsio threads used to service asynchronous I/O requests on an NFS _client_ machine. Your diff seems to imply that this affects the _server_. However, on the client, vfs.nfs.iothreads jumps to 4 as soon as I mount the NFS share. On the server, it stays at -1. On the client, when I start copying from the server, it stays at 4; on the server it stays at -1. Same when I copy the other way round. So it really seems to affect the client (as sysctl(8) currently says), which I think makes your diff incorrect. After I unmount the share on the client, vfs.nfs.iothreads stays on 4; I set that manually to -1, and it jumps to 20, without even having anything NFS-mounted. Is that intended? Setting it manually to anything but -1 then panicked my 5.2/i386 client. (I would try current, but that's currently not bootable on my i386 laptop.) Jan
Re: Panic at pmap_remove_ptes, 5.2/i386
On 19 December 2012 21:22, Stuart Henderson wrote: > On 2012-12-18, Marcin wrote: >> I found an older thread with Stuart reporting similar issue here >> http://marc.info/?l=openbsd-tech&m=132593610913252 > > Frequent is kind-of good ;) I had a few crashes close together but > then nothing (and I've moved most of those boxes to amd64 by now). Thanks for reply! I was not sure if amd64 port is mature enough, but changing architecture is definitely an option. > Really you'll want some way to log DDB output (serial console > preferably, unless you are lucky and the dmesg buffer survives > a reboot) and at least run "show all pools" as well as the usual > trace / ps. Yes, I set up ddb options on one of the machines to get more info, unfortunately it wasn't the one which crashed few hours ago :). Intriguingly, the frequency of crashes seems to decrease, one of the machines ran for exactly 8 days (+/- 15 minutes) before it crashed. Cheers, -- Marcin
Re: vfs.nfs.iothreads
On Sun, Dec 23, 2012 at 08:17:01PM +0100, Jan Stary wrote: > > Yes, on the _client_ (sorry, I should have been explicit). > What got me trying it is that sysctl(8) says > > To adjust the number of kernel nfsio threads > used to service asynchronous I/O requests on > an NFS _client_ machine. > > Your diff seems to imply that this affects the _server_. > > However, on the client, vfs.nfs.iothreads jumps to 4 > as soon as I mount the NFS share. On the server, it stays at -1. > > On the client, when I start copying from the server, it stays at 4; > on the server it stays at -1. Same when I copy the other way round. > > So it really seems to affect the client (as sysctl(8) currently says), > which I think makes your diff incorrect. > > After I unmount the share on the client, vfs.nfs.iothreads > stays on 4; I set that manually to -1, and it jumps to 20, > without even having anything NFS-mounted. Is that intended? > Setting it manually to anything but -1 then panicked my > 5.2/i386 client. (I would try current, but that's currently > not bootable on my i386 laptop.) > ok, so unless someone steps up and explains to me how this is meant to work i can;t do much... jmc
Kernel Debugging
I was looking into kernel debug options and found that trying to build a kernel with kgdb option enabled fails. Anyone using the kgdb setup? I can use ddb it's just painful to have to manually walk structures to examine values. I have moved on to plan B which was to build with option DDB_STRUCT and the build is a success but the 'show struct' command always returns 'unknown structure' for anything other than mbuf. Anyone have any kernel debugging strategies they'd like to share? Justin [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
openbsd live cd installable?
Hello, for the longest time I try to read more material useful for openbsd to learn as much as possible, I bought the book :) I always follow the project carefully because it is my preferred system, I have done many tests with the system but i never managed to create a live cd installable, there are links to the live version but it is not installable. Dovo I can find some information material on this? greetings -- Cardi Francesco alias Il Parente Free Software activist CEO/President Movimento Culturale GNU CODICE LIBERO Diaspora*: https://joindiaspora.com/u/ilparente Identi.ca: https://identi.ca/cardifrancesco Jabber: ilpare...@jabber.org
Re: openbsd live cd installable?
Francesco Cardi wrote: >Hello, for the longest time I try to read more material useful for >openbsd to learn as much as possible, I bought the book :) I always >follow the project carefully because it is my preferred system, I have >done many tests with the system but i never managed to create a live >cd installable, there are links to the live version but it is not >installable. >Dovo I can find some information material on this? "Dovo"? Did google translate this for you? ;-) Anyway, what's a "live cd installable"? Isn't the point of a live cd that you *don't* install it?
Re: Kernel Debugging
On Sun, Dec 23, 2012 at 1:34 PM, Justin Mayes wrote:
> I was looking into kernel debug options and found that trying to build a
> kernel with kgdb option enabled fails.
If no one uses it, it won't keep working. Submitting a patch to fix
the build would be a first step. I suggest trying it both with DDB
and without DDB: those should both work.
> Anyone using the kgdb setup? I can
> use ddb it's just painful to have to manually walk structures to examine
> values. I have moved on to plan B which was to build with option DDB_STRUCT
> and the build is a success but the 'show struct' command always returns
> 'unknown structure' for anything other than mbuf. Anyone have any kernel
> debugging strategies they'd like to share?
DDB_STRUCT works for me for other structures. For example, here's a
session looking at a firefox struct proc:
Stopped at Debugger+0x5: leave
ddb{0}> ps/a
PID COMMAND STRUCT PROC * UAREA * VMSPACE/VM_MAP
16253 firefox 0xfe812af09798 0x800032dd6000 0xfe81305ec1d0
8061 xpdf0xfe81280e1a08 0x800032dfe000 0xfe81305ecd30
31009 firefox 0xfe81280e17a0 0x800032df9000 0xfe81305ec1d0
5390 firefox 0xfe81280e1c70 0x800032e0d000 0xfe81305ec1d0
10871 less0xfe81280e1068 0x800032df4000 0xfe81305ece10
28672 vi 0xfe8129b0d7a8 0x800032e16000 0xfe81305ecb70
24081 firefox 0xfe81280e12d0 0x800032def000 0xfe81305ec1d0
29697 firefox 0xfe812af09c68 0x800032de5000 0xfe81305ec1d0
19401 firefox 0xfe812af09a00 0x800032de 0xfe81305ec1d0
27330 firefox 0xfe8135a2b4f0 0x800032ddb000 0xfe81305ec1d0
13735 firefox 0xfe812af09530 0x800032dd1000 0xfe81305ec1d0
819 firefox 0xfe812af092c8 0x800032dcc000 0xfe81305ec1d0
13812 firefox 0xfe812de71c60 0x800032dc2000 0xfe81305ec1d0
15769 firefox 0xfe812af09060 0x800032dc7000 0xfe81305ec1d0
2108 firefox 0xfe812de719f8 0x800032dbd000 0xfe81305ec1d0
7957 firefox 0xfe812de71790 0x800032db8000 0xfe81305ec1d0
20128 firefox 0xfe812de71528 0x800032db3000 0xfe81305ec1d0
4339 firefox 0xfe812de712c0 0x800032da6000 0xfe81305ec1d0
20161 firefox 0xfe812de71058 0x800032da1000 0xfe81305ec1d0
4258 firefox 0xfe812f591c58 0x800032d9c000 0xfe81305ec1d0
4495 firefox 0xfe812f5919f0 0x800032d8f000 0xfe81305ec1d0
ddb{0}> show struct
proc 0xfe812af09798
struct proc at 0xfe812af09798 (616 bytes)
p_runq 16
p_list 16
p_p8 fe81368ad7c8
p_thr_link 16
p_fd 8 fe81377d1898
p_vmspace 8 fe81305ec1d0
p_sigacts 8 fe8136f246c0
p_exitsig 40
p_flag 4 4100080
p_spare1 ef
p_stat 13
p_pad1 1 af
p_descfd 1 de
p_pid 4 3f7d
p_hash 16
p_dupfd40
p_thrslpid 82309e1800
p_sigwait 40
p_estcpu 40
p_cpticks 40
p_pctcpu 40
p_wchan8 fe812af09810
p_sleep_to 40
p_wmesg8 8083585c
p_swtime 4 32
p_slptime 4e
p_cpu 8 801c1000
p_ru 144
p_tu 40
p_rtime16
p_uticks 40
p_sticks 40
p_iticks 40
p_systrace 80
p_siglist 40
p_textvp 8 fe812e522160
p_emuldata 80
p_sigdivert40
p_sigmask 40
p_priority 1 32
p_usrpri 1 32
p_comm[17] 1 66 69 72 65 66 6f 7800
00000000
p_emul 8 80a4eb00
p_sigstk
Re: openbsd live cd installable?
>On 24 December 2012 00:09, Alexander Hall wrote: > Anyway, what's a "live cd installable"? Isn't the point of a live cd that you > *don't* install it? > Nope - for several Linux and other live OS installations the initial boot is install-less, but there's an option to install to media once the boot is complete PK
Re: openbsd live cd installable?
On 12/23/12 17:24, Francesco Cardi wrote: > Hello, for the longest time I try to read more material useful for > openbsd to learn as much as possible, I bought the book :) I always > follow the project carefully because it is my preferred system, I have > done many tests with the system but i never managed to create a live > cd installable, there are links to the live version but it is not > installable. > Dovo I can find some information material on this? > > > greetings > Understand how things work and it's trivial. Sounds like you already found a "Live CD" version of OpenBSD. I fail to understand the point, but they are out there, some people like 'em great (be aware, they ARE unofficial...but then, so is this advice). You want to install, too? ok, if it isn't there already, put bsd.rd in the root file system. Put the install files in the same place they'd be in the install CD. When you boot it, specify "bsd.rd" instead of the default kernel, ta-da, you got an install disk. You will probably want to use a DVD, as you won't have a lot of spare space for running files, install files and applications. Or just build yourself a usb disk. MUCH more useful, 'cept for really old machines which don't boot from USB. Nick.
