Soporte Técnico para PC y Redes.
[IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] La libre distribucisn de este email esta autorizada por la Ley 26.032 por tratarse de Difusisn de Informacisn.Este email fue enviado a: %%emailaddress%%Si desea desuscribirse, puede hacerlo con un clic aquiLa libre distribucisn de este email esta autorizada por la Ley 26.032 por tratarse de Difusisn de Informacisn.Si desea desuscribirse, puede hacerlo con un clic aqui
HazLink: Email Marketing para tu empresa
Si no puedes visualizar este correo, haz click aqum. Base de Datos Confiable y segmentada a nivel local, regional, nacional y nichos especmficos de trabajo, de esta manera garantizamos estar en la mente de tus consumidores. Tecnologma Nuestro sistema profesional de envio masivo de correo electrsnico, nos permite realizar campaqas totalmente personalizadas, generar reportes en tiempo real para supervisar la actividad de tu publicidad. Diseqo Contamos con especialistas en la comunicacisn grafica para garantizar el exito y el link con tus consumidores. Este mensaje ha sido enviado a travis de HAZLINK. Con respeto a las leyes nacionales e internaciones las cuales nos rigen y siendo respetuosos con la privacidad de su persona, este correo puede ser removido haciendo CLICK en el enlace que se encuentra en la parte inferior de este mensaje. Este envmo no es considerado Spam, mientras se incluya la forma de ser removido. Polmtica de privacidad ?Deseas dejar de recibir este correo? Anula tu suscripcisn en este link.
Re: security(8) and maildir
Hi, Zi Loff wrote on Thu, Apr 12, 2012 at 10:43:32AM +0100: security(8) complains about the permissions of my postfix's virtual hosts maildir, I assume because of the directory mode bit. I once found a patch to /usr/libexec/security that fixed it, but I can't seem to find it anywhere now. IIRC, it was a small fix to nag S_IMODE($mode) != (S_IRUSR | S_IWUSR), but I lack the skills to fix it myself. Can anyone give me a hand? It's not that important, really, I'm just trying to avoid all the daily insecurity outputs I get stating nothing but this problem... It is hard to guess what you need from the scarce information you provide. Can you show the output of # ls -al /var/mail on the machine in question, and the exact messages you see in your daily security emails? Then again, if that directory contains anything else except one mailbox per user, i'm not sure it's wise to put that data in /var/mail, that might confuse more than one program. In case you insist to keep non-standard data in /var/mail, the easiest way to get rid of the warnings probably is to comment the two lines $check_title = Checking mailbox ownership.; check_mailboxes; in /usr/libexec/security; but note that you have to do that again each time you update the operating system, so moving your data somewhere else may be easier. Right now, i don't see how i could improve the official security(8) script in this respect. Yours, Ingo
Re: spamd-setup in crontab
I had the same problem. I found that changing the default timing fixed it. Thousands of OpenBSD default crons hitting openbsd.org at the same time. Le 14/11/2011 10:13, Manuel Giraud a C)crit : Hi, I've just set up a mail server with 5.0. I have put spamd in front (in default greylisting mode). It works great following the man pages but when I activate the spamd-setup entry in root's crontab, I receive the following error by mail: spamd-setup: ftp: Could not add blacklist uatrapsWriting -: : Illegal seek Broken pipe If i call spamd-setup as root i have no error message. (note: I've used the default /etc/mail/spamd.conf file). How can I sort this out?
Re: Kernel roughing in tool
On Sat, Apr 14, 2012 at 10:21:27AM +1000, David Diggles wrote: What a waste of time. And it is well known that we don't even look at problem reports that use a custom kernel. A sore point perhaps? This has nothing to do with that. You are told by the experts (developers) to not do something. Of course you are free ignore that advice and to do otherwise. But don't expect encouragment or support. Still worth noting, there is sometimes a reason to modify a kernel or cut down its size, and that is why the procedure is documented on openbsd.org. And as explained in FAQ section 5.6, there are many more reasons not to do it. -Otto
Re: Kernel roughing in tool
Otto Moerbeek o...@drijf.net writes: And as explained in FAQ section 5.6, there are many more reasons not to do it. and amplified by 5.7 It is assumed you have read the above[Section 5.6], and really enjoy pain. before it proceeds to a description of how you would go about customizing. - 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: Areca ARC-1213-4i or ARC-1223-8i using arc(4) for hardware RAID?
On 2012-04-12 22.23, Richard Johnson wrote: We're looking at Areca ARC-1213-4i or ARC-1223-8i [1] cards for doing RAID 5, 6 or 10 arrays. http://www.areca.com.tw/products/sas6g_internal.htm They're not listed on the OpenBSD-current man page for arc(4). They're reported by some to be essentially the same as the long-discontinued ARC-1210/1220, however, which is listed as supported. I believe that is incorrect, unfortunately. See below. Is there any particular reason the ARC-1212-4i or ARC-1223-8i will not work with OpenBSD 5.1 and newer's arc(4) driver? (Will arc(4) deal with Areca's generically named RAID-on-chip (ROC), listed in specs for the 1213, vs. their more specific IOP3## RAID processors listed for the ARC-1231ML et al? Is there actually a significant difference there?) I suspect they are equipped with the same ROC controller that the ARC-1880 series uses. I don't recall at the moment exactly what controller it is, but it definitely is not the Intel IOP348 that's in some of the other ARC-1200 series (as well as ARC-1680), and it is AFAIK *not* presently supported by the arc(4) driver. Which is unfortunate, since they are excellent controllers with much bang for the buck. I actually made a stab at implementing support for the ARC-1880i using the FreeBSD driver as inspiration, but alas ran out of time on the project I was intent on using them in, so we had to revert to ARC-1680i (which are now unfortunately no longer sold). If you have experience with the ARC-1213 or 1223, what did you find? Thanks in advance. Regards, /Benny -- internetlabbet.se / work: +46 8 551 124 80 / Words must Benny Lofgren/ mobile: +46 70 718 11 90 / be weighed, / fax:+46 8 551 124 89/not counted. /email: benny -at- internetlabbet.se
smtpd(8), aliases(5), forward(5): non-zero exit code causes deliveries abort
hello (opensmtpd-) folks, I think OpenSMTPd aborts delivery to multiple aliased recipients as soon as a delivery attempt returns non-zero. I consider this unwanted: a super user defined delivery list in aliases(5) is not applied if some foolish luser messes up her/his .forward. How I found out about this: in aliases(5): foobar: b_user, a_user (Verbose log shows this get's reordered to a_user, b_user. I'm not sure that is good.) forward(5) of a_user (that's the one tried first) |/usr/local/bin/procmail after that delivery to b_user is not attempted. If I change a_user's forward(5) to |/usr/local/bin/procmail; exit 0 delivery to b_user is attempted. Bye, Marcus
Re: smtpd(8), aliases(5), forward(5): non-zero exit code causes deliveries abort
On Sat, Apr 14, 2012 at 07:48:24PM +0200, MERIGHI Marcus wrote: hello (opensmtpd-) folks, I think OpenSMTPd aborts delivery to multiple aliased recipients as soon as a delivery attempt returns non-zero. I consider this unwanted: a super user defined delivery list in aliases(5) is not applied if some foolish luser messes up her/his .forward. How I found out about this: in aliases(5): foobar: b_user, a_user (Verbose log shows this get's reordered to a_user, b_user. I'm not sure that is good.) forward(5) of a_user (that's the one tried first) |/usr/local/bin/procmail after that delivery to b_user is not attempted. If I change a_user's forward(5) to |/usr/local/bin/procmail; exit 0 delivery to b_user is attempted. Bye, Marcus Hi Marcus, This is actually a known issue which is in my todo. What we do currently is generate a list of valid recipients and a list of failed recipients. When we end the aliases expansion with a failed list that's not empty we reject the entire batch. In practice, we should simply iterate over the failed list and generate a bounce, however we are unhappy with the current bounce code. Don't worry, it will be fixed soon as I started playing with OpenSMTPD powered mailing lists ;-) -- Gilles Chehade https://www.poolp.org | http://pool.ps @poolpOrg
OpenBSD 5.1 SSD
Hi, I'm considering purchasing a domestic SSD for my laptop. Does OpenBSD 5.1 support SSDs and the TRIM command if needed? Regards, Laurence Rochfort
Re: smtpd(8), aliases(5), forward(5): non-zero exit code causes deliveries abort
hello Gilles, gil...@poolp.org (Gilles Chehade), 2012.04.14 (Sat) 20:18 (CEST): On Sat, Apr 14, 2012 at 07:48:24PM +0200, MERIGHI Marcus wrote: hello (opensmtpd-) folks, I think OpenSMTPd aborts delivery to multiple aliased recipients as soon as a delivery attempt returns non-zero. I consider this unwanted: a super user defined delivery list in aliases(5) is not applied if some foolish luser messes up her/his .forward. How I found out about this: in aliases(5): foobar: b_user, a_user (Verbose log shows this get's reordered to a_user, b_user. I'm not sure that is good.) I was wrong there; the alias expansion is printed in reordered fashion to the log; delivery is attempted in the specified order. forward(5) of a_user (that's the one tried first) |/usr/local/bin/procmail after that delivery to b_user is not attempted. If I change a_user's forward(5) to |/usr/local/bin/procmail; exit 0 delivery to b_user is attempted. This is actually a known issue which is in my todo. that's good to know. Thanks (over and over again)! What we do currently is generate a list of valid recipients and a list of failed recipients. When we end the aliases expansion with a failed list that's not empty we reject the entire batch. further testing of my workaround ``|/usr/local/bin/procmail; exit 0'' showed that it works for two recipients (expanded from aliases) but not for three; a test of the shell thingy: sudo su -l someuser -c cat /somepath/testmail | /bin/sh -c \ '/usr/local/bin/procmail || print FAIL print SUCC' prints SUCC. Therefore I see no real error condition there? The further testing was somewhat confusing: ordering of recipients in aliases(5) matters; also, which recipient got the ``|| exit 0'' or ``; exit 0'' in his/her forward(5). Up to two recipients, it seems, it needs to be the second rcpt; with more recipients I never saw a delivery to all of them, no matter who had the ``|| exit 0'' after the procmail call (or all of them). Tests with ``|/bin/cat /dev/null'' in forward(5) made no difference. Maybe it's just that I'm tired. In practice, we should simply iterate over the failed list and generate a bounce, however we are unhappy with the current bounce code. Don't worry, it will be fixed soon as I started playing with OpenSMTPD powered mailing lists ;-) Please elaborate on that! Do you mean just having smtpd deliver to lots of recipients via aliases or something beyond that? Thanks, Marcus
Re: smtpd(8), aliases(5), forward(5): non-zero exit code causes deliveries abort
forgot to mention: doing all of this on OpenBSD 5.1-current (GENERIC) #182: Fri Mar 30 13:51:26 MDT 2012 mcmer-open...@tor.at (MERIGHI Marcus), 2012.04.14 (Sat) 21:30 (CEST): hello Gilles, gil...@poolp.org (Gilles Chehade), 2012.04.14 (Sat) 20:18 (CEST): On Sat, Apr 14, 2012 at 07:48:24PM +0200, MERIGHI Marcus wrote: hello (opensmtpd-) folks, I think OpenSMTPd aborts delivery to multiple aliased recipients as soon as a delivery attempt returns non-zero. I consider this unwanted: a super user defined delivery list in aliases(5) is not applied if some foolish luser messes up her/his .forward. How I found out about this: in aliases(5): foobar: b_user, a_user (Verbose log shows this get's reordered to a_user, b_user. I'm not sure that is good.) I was wrong there; the alias expansion is printed in reordered fashion to the log; delivery is attempted in the specified order. forward(5) of a_user (that's the one tried first) |/usr/local/bin/procmail after that delivery to b_user is not attempted. If I change a_user's forward(5) to |/usr/local/bin/procmail; exit 0 delivery to b_user is attempted. This is actually a known issue which is in my todo. that's good to know. Thanks (over and over again)! What we do currently is generate a list of valid recipients and a list of failed recipients. When we end the aliases expansion with a failed list that's not empty we reject the entire batch. further testing of my workaround ``|/usr/local/bin/procmail; exit 0'' showed that it works for two recipients (expanded from aliases) but not for three; a test of the shell thingy: sudo su -l someuser -c cat /somepath/testmail | /bin/sh -c \ '/usr/local/bin/procmail || print FAIL print SUCC' prints SUCC. Therefore I see no real error condition there? The further testing was somewhat confusing: ordering of recipients in aliases(5) matters; also, which recipient got the ``|| exit 0'' or ``; exit 0'' in his/her forward(5). Up to two recipients, it seems, it needs to be the second rcpt; with more recipients I never saw a delivery to all of them, no matter who had the ``|| exit 0'' after the procmail call (or all of them). Tests with ``|/bin/cat /dev/null'' in forward(5) made no difference. Maybe it's just that I'm tired. In practice, we should simply iterate over the failed list and generate a bounce, however we are unhappy with the current bounce code. Don't worry, it will be fixed soon as I started playing with OpenSMTPD powered mailing lists ;-) Please elaborate on that! Do you mean just having smtpd deliver to lots of recipients via aliases or something beyond that? Thanks, Marcus
Re: OpenBSD 5.1 SSD
On Sat, Apr 14, 2012, Laurence Rochfort wrote: Hi, I'm considering purchasing a domestic SSD for my laptop. Does OpenBSD 5.1 support SSDs and the TRIM command if needed? It supports SSD drives like any other drive, but no special features. Specifically, there's no TRIM support.
Re: OpenBSD 5.1 SSD
doesn't support trim. i remember reading somewhere, maybe a freebsd mailing list, that calculating when to do trim is tricky because it can only work on a specific width On Sat, Apr 14, 2012 at 2:08 PM, Laurence Rochfort laurence.rochf...@gmail.com wrote: Hi, I'm considering purchasing a domestic SSD for my laptop. Does OpenBSD 5.1 support SSDs and the TRIM command if needed? Regards, Laurence Rochfort
Re: smtpd(8), aliases(5), forward(5): non-zero exit code causes deliveries abort
MERIGHI Marcus mcmer-open...@tor.at wrote: hello Gilles, gil...@poolp.org (Gilles Chehade), 2012.04.14 (Sat) 20:18 (CEST): On Sat, Apr 14, 2012 at 07:48:24PM +0200, MERIGHI Marcus wrote: hello (opensmtpd-) folks, I think OpenSMTPd aborts delivery to multiple aliased recipients as soon as a delivery attempt returns non-zero. I consider this unwanted: a super user defined delivery list in aliases(5) is not applied if some foolish luser messes up her/his .forward. How I found out about this: in aliases(5): foobar: b_user, a_user (Verbose log shows this get's reordered to a_user, b_user. I'm not sure that is good.) I was wrong there; the alias expansion is printed in reordered fashion to the log; delivery is attempted in the specified order. forward(5) of a_user (that's the one tried first) |/usr/local/bin/procmail after that delivery to b_user is not attempted. If I change a_user's forward(5) to |/usr/local/bin/procmail; exit 0 delivery to b_user is attempted. This is actually a known issue which is in my todo. that's good to know. Thanks (over and over again)! What we do currently is generate a list of valid recipients and a list of failed recipients. When we end the aliases expansion with a failed list that's not empty we reject the entire batch. further testing of my workaround ``|/usr/local/bin/procmail; exit 0'' showed that it works for two recipients (expanded from aliases) but not for three; a test of the shell thingy: sudo su -l someuser -c cat /somepath/testmail | /bin/sh -c \ '/usr/local/bin/procmail || print FAIL print SUCC' Such a construct would always print SUCC. Well, unless both procmail and print FAIL fails... /Alexander prints SUCC. Therefore I see no real error condition there? The further testing was somewhat confusing: ordering of recipients in aliases(5) matters; also, which recipient got the ``|| exit 0'' or ``; exit 0'' in his/her forward(5). Up to two recipients, it seems, it needs to be the second rcpt; with more recipients I never saw a delivery to all of them, no matter who had the ``|| exit 0'' after the procmail call (or all of them). Tests with ``|/bin/cat /dev/null'' in forward(5) made no difference. Maybe it's just that I'm tired. In practice, we should simply iterate over the failed list and generate a bounce, however we are unhappy with the current bounce code. Don't worry, it will be fixed soon as I started playing with OpenSMTPD powered mailing lists ;-) Please elaborate on that! Do you mean just having smtpd deliver to lots of recipients via aliases or something beyond that? Thanks, Marcus
Re: OpenBSD 5.1 SSD
On 04/14/12 20:38, Laurence Rochfort wrote: Hi, I'm considering purchasing a domestic SSD for my laptop. Does OpenBSD 5.1 support SSDs and the TRIM command if needed? As already said; yes and no, respectively. It matters little though, but if you're really concerned about the missing TRIM support, don't partition the entire disk but leave a part of it unused. That said, just buy one and enjoy the ride. Ohmigod it's nice. :) /Alexander Regards, Laurence Rochfort
Re: OpenBSD 5.1 SSD
Thank you everybody. I don't really use much space locally as my videos etc are on the network. I'll leave some space unpartitioned and let garbage collection do the rest. Many thanks, Laurence On Apr 15, 2012 12:09 AM, Alexander Hall ha...@openbsd.org wrote: On 04/14/12 20:38, Laurence Rochfort wrote: Hi, I'm considering purchasing a domestic SSD for my laptop. Does OpenBSD 5.1 support SSDs and the TRIM command if needed? As already said; yes and no, respectively. It matters little though, but if you're really concerned about the missing TRIM support, don't partition the entire disk but leave a part of it unused. That said, just buy one and enjoy the ride. Ohmigod it's nice. :) /Alexander Regards, Laurence Rochfort
Re: OpenBSD 5.1 SSD
On 2012-04-14, Ted Unangst t...@tedunangst.com wrote: On Sat, Apr 14, 2012, Laurence Rochfort wrote: Hi, I'm considering purchasing a domestic SSD for my laptop. Does OpenBSD 5.1 support SSDs and the TRIM command if needed? It supports SSD drives like any other drive, but no special features. Specifically, there's no TRIM support. dlg did some work towards this on scsi-like controllers, but iirc it's not passed all the way up to the filesystem yet. Recent releases will align partitions better for most flash devices (and newer hard drives) than older ones, people with SSD/CF storage might want to check if disklabel says the offset of the 'a' partition is 63 or 64, if it's 63 then it may be worth reinstalling with newer fdisk/disklabel. Probably depends on the controller how much effect this will have though.
Re: Areca ARC-1213-4i or ARC-1223-8i using arc(4) for hardware RAID?
At 17:29 +0200 on 2012-04-14, Benny Lofgren wrote: On 2012-04-12 22.23, Richard Johnson wrote: Is there any particular reason the ARC-1212-4i or ARC-1223-8i will not work with OpenBSD 5.1 and newer's arc(4) driver? (Will arc(4) deal with Areca's generically named RAID-on-chip (ROC), listed in specs for the 1213, vs. their more specific IOP3## RAID processors listed for the ARC-1231ML et al? Is there actually a significant difference there?) I suspect they are equipped with the same ROC controller that the ARC-1880 series uses. I don't recall at the moment exactly what controller it is, but it definitely is not the Intel IOP348 that's in some of the other ARC-1200 series (as well as ARC-1680), and it is AFAIK *not* presently supported by the arc(4) driver. Which is unfortunate, since they are excellent controllers with much bang for the buck. Thanks. Indeed, this site: http://www.osslab.com.tw/Storage/Enterprise/SAS%E8%88%87RAID/SAS//SATA//RAID_HBA,_IOP%E5%92%8CIOC%E8%B3%87%E8%A8%8A suggests that the ARC-1880 RAID-on-Chip (ROC) is based on LSI SAS 2108. It seems likely that the ARC-1213 1223 cards are also based on LSI SAS2108 or something close. The fact that Areca are being cagey about specifying the processor hints, at minimum, at their reserving the option to make under-the-hood changes. I actually made a stab at implementing support for the ARC-1880i using the FreeBSD driver as inspiration, but alas ran out of time on the project I was intent on using them in, so we had to revert to ARC-1680i (which are now unfortunately no longer sold). I see some lingering ARC-1680s for sale, so that's possibly still an option for this system, and maybe for lists if I can't find another easier way to a RAID 6 capable system to offer there. The ARC-1212 and ARC-1222 are still more readily available from distributors. They're not listed as explicitly supported by arc(4) man page, but at least they're Intel (-Marvell) IOP348-based. However, there's this thread termination from 2010 that suggests the ARC-1212 may be detected as the ARC-1680, such that bioctl can't report the array status. http://archives.neohapsis.com/archives/openbsd/2010-09/1206.html . I don't see anything in current sources that shows differentiation/mention of PCI_PRODUCT_ARECA_ARC1222, but I am not necessarily looking in all the right places. Richard
