Notebook
Hello. I recently bought an Acer 5552-7858 notebook. While shopping I checked that OpenBSD had drivers for all the devices, and my dmesg has no "not configured" messages. The video, webcam, and audio are working well. This is a low price AMD quad core, well loaded with 6GB of memory and 640GB of storage, 15.4 inch monitor, full size keyboard, and after 2 weeks I recommend it. I have a few issues that I would like help with. I installed VLC, and my webcam works, but my microphone does not seem to be detected at all. dmesg does not list a usb audio device. What should I do to investigate this? Is there a better application, other than VLC, for using a webcam with OpenBSD? Second, I configured KDE to use a blank screen saver, which works, but the monitor never turns off. How can I configure my notebook monitor to turn off after 15 minutes of being inactive? Third, my touchpad is slow... the cursor move slowly. I tried to configure it with KDE to behave faster, but KDE isn't making it behave the way I am used to with Linux. Are there any suggestions for this? I don't seem to be using the Synaptics driver. The touchpad otherwise works... scrolling works, and a double finger tap simulates the (missing) middle button. I am also curious about how SMP behaves. According to top(1), an application may be using 50% cpu, while all the cpu's are 85% idle. Does OpenBSD somehow divide the load over the cpu's, or is top(1) not displaying things properly? And lastly, is there something equivalent to the GNU free(1) command? Thank you Robert
Aromatizador automatico | Pochoclera Automatica | Juego de Cocina | Cuchillo Deli Pro | Test de Alcoholemia | Cena Gourmet en Brands | Camara de Fotos Samsung
Para visualizar correctamente este newsletter ingresa a http://news1.bonuscupon.com.ar/r.html?uid=1.l.29hh.bm.ap265n1ol0
Re: spamd greylisting: false positives
This may seem like a dead horse to some by now, but I am disappointed
no one replied to the msg, I supplied the detailed event information with
timestamps, regarding lists.openbsd.org mails not being whitelisted by
spamd when run in greylist mode.
RFC282, 4.5.4.1 Sending Strategy:
The sender MUST delay retrying a particular destination after one
attempt has failed. In general, the retry interval SHOULD be at
least 30 minutes; however, more sophisticated and variable strategies
will be beneficial when the SMTP client can determine the reason for
non-delivery.
Retries continue until the message is transmitted or the sender gives
up; the give-up time generally needs to be at least 4-5 days. The
parameters to the retry algorithm MUST be configurable.
Yet I have been advised not to mess with the default timings with -G option.
It looks to me like the retry intervals of lists.openbsd.org are not
sufficient to get it whitelisted by spamd.
I am well beyond assuming anything, and prepared to learn / accept
any constructive advice.
Can anyone confirm they have the following scenario?
* A clean installed OpenBSD 5.1 configured as a primary MX
* Clean spamd settings, clean /var/db/spamd
* Default spamd with no options
* Default spamlogd with no options
* The pf.conf uses spamd entries from the example pf.conf from etc.tgz
* No manual whitelist entry for lists.openbsd.org
* Incoming from lists.openbsd.org is eventually whitelisted by spamd
I am just trying to learn the cause, and I have been fully prepared to wear
egg on my face if my own configuration is causing the problem. I have not
yet proven this is the case.
I believe I have checked everything anyone suggested to check.
I really don't want my next check be to roll back to 4.9 and see if
lists.openbsd.org will auto whitelist like it previously did.
In hope,
David
On Sat, May 26, 2012 at 01:19:38PM +1000, David Diggles wrote:
> Ok I am still not getting emails from
> lists.openbsd.org (so please if you reply, cc to me).
>
> I restarted spamd at this time after deleting /var/db/spamd and
> clearing the bypass tables in pf at this time:
>
> 2012-05-26 02:13:12 # /usr/libexec/spamd
>
> Here is the last message to make it to sendmail from misc:
>
> fgrep from= /var/log/maillog|fgrep owner-misc|tail -1|awk '{print $1,$2,$3}'
> May 26 01:54:35
>
> The pf rules for spamd I have are taken from the default pf.conf:
>
> pass in on egress inet proto tcp from any to any port = 25 flags S/SA rdr-to
> 127.0.0.1 port 8025
> pass in on egress proto tcp from to any port = 25 flags S/SA
> pass in log on egress proto tcp from to any port = 25 flags S/SA
> pass out log on egress proto tcp from any to any port = 25 flags S/S
>
> It is currently Sat May 26 12:54:31 EST 201
>
> Times of passed smtp connections for May 26:
>
> tcpdump -n -e -ttt -r /var/log/pflog 2>&1|fgrep ".25:"|\
> fgrep 'May 26'|awk '{print $3}'
> 01:14:53.793995
> 04:17:11.846707
> 05:00:19.443080
> 05:15:01.487277
> 07:17:51.114440
> 09:35:58.120098
> 10:14:21.444822
> 11:53:33.611903
>
> So I will skip the first entry when I grep for the
> ip addresses, with a tail +2 because it occurred
> *before* I reset everything.
>
> tcpdump -n -e -ttt -r /var/log/pflog 2>&1|fgrep ".25:"|\
> fgrep 'May 26'|awk '{print $10}'|tail +2|\
> awk -F. '{print $1"."$2"."$3"."$4}'|sort -n
> 17.254.6.112
> 74.125.82.47
> 113.172.232.215
> 129.21.208.44
> 202.58.38.80
> 203.59.1.110
> 206.46.252.115
>
> I have the following tables.
>
> pfctl -s Tables
> nospamd
> spamd-white
>
> Confirming against the spamd-white table
>
> pfctl -t spamd-white -Ts
>17.254.6.112
>74.125.82.47
>113.172.232.215
>129.21.208.44
>202.58.38.80
>203.59.1.110
>206.46.252.115
>
> lists.openbsd.org = 192.43.244.163
>
> So nothing from misc has made it to sendmail since I emptied
> and on pf.conf
>
> These are all the attempts from lists.openbsd.org since
> I cleared the spamdb and pf tables.
>
> fgrep 192.43.244.163 /var/log/spamd|fgrep 'May 26'
> May 26 02:53:48 skitL spamd[25502]: 192.43.244.163: connected (1/0)
> May 26 02:54:00 skitL spamd[25502]: 192.43.244.163: disconnected after 12
> seconds.
> May 26 03:00:24 skitL spamd[25502]: 192.43.244.163: connected (1/0)
> May 26 03:00:36 skitL spamd[25502]: 192.43.244.163: disconnected after 12
> seconds.
> May 26 04:41:24 skitL spamd[25502]: 192.43.244.163: connected (1/0)
> May 26 04:41:36 skitL spamd[25502]: 192.43.244.163: disconnected after 12
> seconds.
> May 26 05:04:19 skitL spamd[25502]: 192.43.244.163: connected (2/1)
> May 26 05:04:31 skitL spamd[25502]: 192.43.244.163: disconnected after 12
> seconds.
> May 26 05:15:24 skitL spamd[25502]: 192.43.244.163: connected (1/0)
> May 26 05:15:36 skitL spamd[25502]: 192.43.244.163: disconnected after 12
> seconds.
> May 26 05:19:36 skitL spamd[25502]: 192.43.244.163: connected (1/0)
> May 26 05:19:48 skitL spamd[25502]: 192.43.244.163: disconnected after 12
> s
Re: pf faq
On 2012-05-26, Jan Stary wrote: >> > If someone wants to carefully go over faq/pf/ (or at least going >> > over one whole page rather than just parts of a page), check/update things >> > and send a diff, that would be very nice and there's a good chance it would >> > get committed.. to clarify: I will review a diff for a whole page or for the whole pf section, but cannot go over a bunch of small patches for various things, and indeed I think that is the wrong approach, it will be much more readable and consistent if each page is treated as a complete unit.
Re: Recent BIND ports
http://thread.gmane.org/gmane.os.openbsd.ports/47730 - it would want updating as well as fixing. Kostas Zorbadelos wrote: Stuart Henderson writes: > On 2012-05-25, Kostas Zorbadelos wrote: >> The question is, is there an interest in developing relevant ports? Is >> someone working on this? > > There are searchable mailing list archives, you know... > A quick search showed nothing but to be honest I didn't try hard enough and I thought asking was cheaper :) >> stupid NXDOMAIN Redirection >> (hopefully we won't need that) (9.9). >so sad that this got added. ISC were some of the first and most >vocal opponents of this mess when netsol started doing it, even >added an option to BIND to filter it per-zone... :) Vixie's logic I think was something along the lines "since more and more people are asking for it and we can't stop it, at least let BIND implement it in a "correct" way..."
Recordatorio para el curso de "Organización y Conservación de Archivos Oficiales"
!Muy Importante! Si no puede visualizar correctamente este correo, le pedimos que lo arrastre a su bandeja de entrada. Apreciable Ejecutivo: TIEM de Mixico Empresa Lmder en Capacitacisn y Actualizacisn de Capital Humano Pone a su disposicisn este excelente curso denominado: "Organizacisn y Conservacisn de Archivos Oficiales" Para la Administracisn Pzblica Mixico D.F. el dma 30 de Mayo 2012 !Zltimos Lugares! Lunes 28 de Mayo ultimo dma para obtener un descuento del 15% con Inversisn Inmediata Ademas por cada dos participantes inscritos en tarifa de Inversisn normal, el tercero es completamente gratis No deje pasar esta oportunidad e Invierta en su Desarrollo Personal y Profesional Todas las oficinas generan un archivo corriente, que es necesario mantener ordenado y suficientemente identificado. Resulta una prioridad para las secretarias y asistentes tener plenamente identificadas las agrupaciones documentales que se encuentran a su cargo. Por esta razsn, los documentos que se generan en archivo de gestisn, deben mantener una estructura organizada y una adecuada clasificacisn que facilite su acceso. Los archivos de Gestisn son fundamentales para la administracisn de cualquier dependencia, toda vez que se tiene un alto nivel de consulta y su acceso debe ser presto, integro y directo, si se quiere tener una unidad que aporte a la organizacisn. Beneficios: Ofrecemos este curso, para que el propio personal que trabaja en las instituciones gubernamentales, aprenda a archivar y servir los documentos de una forma ticnica y estandarizada de acuerdo a los lineamientos de la Ley de Transparencia, para el sector pzblico. Objetivo General: Proporcionar la informacisn necesaria para desarrollar y unificar los archivos de su dependencia; acorde a los lineamientos vigentes de la Ley de Transparencia. Para mayor informacisn, favor de responder este correo con los siguientes datos: Empresa: Nombre: Ciudad: Telifono: O si lo prefiere comunmquese a los telifonos: Del DF al 5611-0969 con 10 lmneas Interior del Pams Lada sin Costo 01 800 900 TIEM (8436) Aceptamos todas las TDC y Dibito. **Promocisn: 3 meses sin Intereses pagando con American Express **Aplica solo con Inversisn Normal .Todos los Derechos Reservados )2011 TIEM Talento e Innovacisn Empresarial de Mixico Este Mensaje le ha sido enviado como usuario de TIEM de Mixico o bien un usuario le refiris para recibir este boletmn. Como usuario de TIEM de Mixico, en este acto autoriza de manera expresa que TIEM de Mixico le puede contactar vma correo electrsnico u otros medios. Si usted ha recibido este mensaje por error, haga caso omiso de il y reporte su cuenta respondiendo este correo con el subject BAJABD Tenga en cuenta que la gestisn de nuestras bases de datos es de suma importancia y no es intencisn de la empresa la inconformidad del receptor.
Re: Recent BIND ports
Stuart Henderson writes: > On 2012-05-25, Kostas Zorbadelos wrote: >> The question is, is there an interest in developing relevant ports? Is >> someone working on this? > > There are searchable mailing list archives, you know... > A quick search showed nothing but to be honest I didn't try hard enough and I thought asking was cheaper :) >> stupid NXDOMAIN Redirection >> (hopefully we won't need that) (9.9). >so sad that this got added. ISC were some of the first and most >vocal opponents of this mess when netsol started doing it, even >added an option to BIND to filter it per-zone... :) Vixie's logic I think was something along the lines "since more and more people are asking for it and we can't stop it, at least let BIND implement it in a "correct" way..."
Re: pf faq
In the final tftp example of ftp.html, is the second anchor line really needed? match out on $ext_if from $int_if nat-to ($ext_if) anchor "tftp-proxy/*" pass in quick on $int_if inet proto udp from $int_if to port tftp \ divert-to 127.0.0.1 port 6969 anchor "tftp-proxy/*" Jan
Re: pf faq
> > If someone wants to carefully go over faq/pf/ (or at least going > > over one whole page rather than just parts of a page), check/update things > > and send a diff, that would be very nice and there's a good chance it would > > get committed.. The http://www.pintday.org/whitepapers/ftp-review.shtml link is broken, and pintday.org is "moving to a new server" for almost exactly a year ... Jan --- ftp.html.orig Sat May 26 19:14:03 2012 +++ ftp.htmlSat May 26 19:14:29 2012 @@ -52,7 +52,6 @@ Gateways] PF "Self-Protecting" an FTP Server FTP Server Protected by an External PF Firewall Running NAT -More Information on FTP Proxying TFTP @@ -243,16 +242,6 @@ connections initiated by ftp-proxy(8) are permitted. Note that if you want to run ftp-proxy(8) to protect an FTP server as well as allow clients to FTP out from behind the firewall that two instances of ftp-proxy will be required. - - - -More Information on FTP -More information on filtering FTP and how FTP works in general can be -found in this whitepaper: - -http://www.pintday.org/whitepapers/ftp-review.shtml";>FTP -Reviewed -
Re: bad 5.1 package of poptop
On 05/26/12 16:41, Marc Espie wrote: On Sat, May 26, 2012 at 02:31:52PM +0200, Federico Giannici wrote: The 5.1 package of poptop "poptop-1.3.4p3.tgz" (taken from 2 different official FTP sites) seems to be compiled for a platform after 5.1. If I try to install it an error appears about a c library version not present: # pkg_add poptop-1.3.4p3.tgz Can't install poptop-1.3.4p3 because of libraries |library c.64.1 not found | /usr/lib/libc.so.50.1 (system): bad major | /usr/lib/libc.so.60.1 (system): bad major | /usr/lib/libc.so.51.0 (system): bad major | /usr/lib/libc.so.53.1 (system): bad major | /usr/lib/libc.so.56.0 (system): bad major | /usr/lib/libc.so.62.0 (system): bad major Duh. Stop wasting our collective time. Hint: snapshots is *not* 5.1. I'm sorry, I found the problem: I downloaded the correct package but clearly when I issued the pkg_add command I erroneously was in another directory so it automatically downloaded the package from the net (I have just found that a lot of time ago I set the PKG_PATH environment variable to snapshots, and I completely forgot it!). Sorry...
Re: pf faq [was Re: (unknown)]
On Sat, May 26, 2012 at 9:30 AM, Stuart Henderson wrote: > On 2012-05-26, Jan Stary wrote: >> The "Passing Traffic" example at >> http://www.openbsd.org/faq/pf/filter.html >> doesn't seem to be completely accurate. >> >> # Pass traffic in on dc0 from the local network, 192.168.0.0/24, >> # to the OpenBSD machine's IP address 192.168.0.1. Also, pass the >> # return traffic out on dc0. >> pass in on dc0 from 192.168.0.0/24 to 192.168.0.1 >> pass out on dc0 from 192.168.0.1 to 192.168.0.0/24 >> >> It's the "return" that bugs me: the first rule alone >> makes the _return_ traffic be passed. The second >> rule allows traffic that originates (creates state) >> on the way out. Right? >> >> > > Probably an incomplete conversion of the faq when the default was changed > to stateful. If someone wants to carefully go over faq/pf/ (or at least going > over one whole page rather than just parts of a page), check/update things > and send a diff, that would be very nice and there's a good chance it would > get committed.. > It allows the router (or other machines not in the network) to reach others computer in the network, and I'm not sure if without that rule you would be able to do ssh 192.168.0.10 to 192.168.0.20 (sine you only got a state 192.168.0.10->192.168.0.1 and not 192.168.0.1->192.168.0.20). It allows for an instance: you want to reach your machine remotely that is behind the firewall 192.168.0.1, you do: 1 - ssh to your router or some machine that the router translates its ip to it. 2 - Access your machine inside the network without nat-ing direct access to it.
Re: bad 5.1 package of poptop
On Sat, May 26, 2012 at 02:31:52PM +0200, Federico Giannici wrote: > The 5.1 package of poptop "poptop-1.3.4p3.tgz" (taken from 2 > different official FTP sites) seems to be compiled for a platform > after 5.1. > > If I try to install it an error appears about a c library version > not present: > > # pkg_add poptop-1.3.4p3.tgz > Can't install poptop-1.3.4p3 because of libraries > |library c.64.1 not found > | /usr/lib/libc.so.50.1 (system): bad major > | /usr/lib/libc.so.60.1 (system): bad major > | /usr/lib/libc.so.51.0 (system): bad major > | /usr/lib/libc.so.53.1 (system): bad major > | /usr/lib/libc.so.56.0 (system): bad major > | /usr/lib/libc.so.62.0 (system): bad major Duh. Stop wasting our collective time. Hint: snapshots is *not* 5.1.
Re: bad 5.1 package of poptop
On Sat, May 26, 2012 at 04:22:41PM +0200, Federico Giannici wrote: > Oops! > I forgot to say it's amd64. carbon:~$ ftp ftp://ftp.eu.openbsd.org/pub/OpenBSD/5.1/packages/amd64/poptop-1.3.4p3.tgz Trying 77.238.36.56... Connected to ftp-prod-srv04.it.su.se. 220 ftp-prod-srv04.it.su.se FTP server ready. 331 Please specify the password. 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. 200 Switching to Binary mode. 250 Directory successfully changed. Retrieving pub/OpenBSD/5.1/packages/amd64/poptop-1.3.4p3.tgz local: poptop-1.3.4p3.tgz remote: poptop-1.3.4p3.tgz 150 Opening BINARY mode data connection for poptop-1.3.4p3.tgz (34753 bytes). 100% |**| 34753 00:00 226 Transfer complete. 34753 bytes received in 0.32 seconds (104.60 KB/s) 221 Goodbye. carbon:~$ tar xzf poptop-1.3.4p3.tgz +CONTENTS carbon:~$ grep wantlib +CONTENTS @wantlib c.62.0 @wantlib util.11.2 There's no problem with the packages. You seem to be mixing snapshots with 5.1 somehow, check your PKG_PATH etc. > > Thanks. > > > > On 05/26/12 16:06, Tobias Ulmer wrote: > >On Sat, May 26, 2012 at 02:31:52PM +0200, Federico Giannici wrote: > >>The 5.1 package of poptop "poptop-1.3.4p3.tgz" (taken from 2 > >>different official FTP sites) seems to be compiled for a platform > >>after 5.1. > >> > >>If I try to install it an error appears about a c library version > >>not present: > >> > >># pkg_add poptop-1.3.4p3.tgz > >>Can't install poptop-1.3.4p3 because of libraries > >>|library c.64.1 not found > >>| /usr/lib/libc.so.50.1 (system): bad major > >>| /usr/lib/libc.so.60.1 (system): bad major > >>| /usr/lib/libc.so.51.0 (system): bad major > >>| /usr/lib/libc.so.53.1 (system): bad major > >>| /usr/lib/libc.so.56.0 (system): bad major > >>| /usr/lib/libc.so.62.0 (system): bad major > >> > >> > >>If I force the install, the ldd command confirm the problem: > >> > >>/usr/local/sbin# ldd ./pptpd > >>./pptpd: > >>./pptpd: can't load library 'libc.so.64.1' > >>./pptpd: exit status 4 > >> > >> > >>Thanks. > >> > > > >On which architecture? > > > >I can observe no such problem: > > > >argon:~$ echo $PKG_PATH > >http://ftp.eu.openbsd.org/pub/OpenBSD/5.1/packages/i386/ > >argon:~$ sudo pkg_add -i poptop > >poptop-1.3.4p3: ok > >The following new rcscripts were installed: /etc/rc.d/pptpd > >See rc.d(8) for details. > >Look in /usr/local/share/doc/pkg-readmes for extra documentation. > >argon:~$ ldd `which pptpd` > >/usr/local/sbin/pptpd: > > StartEnd Type Open Ref GrpRef Name > > 1c00 3c004000 exe 10 0 /usr/local/sbin/pptpd > > 0b939000 2b967000 rlib 01 0 /usr/lib/libc.so.62.0 > > 08d4 08d4 rtld 01 0 /usr/libexec/ld.so > >argon:~$ dmesg|sed 2q > >OpenBSD 5.1 (GENERIC) #160: Sun Feb 12 09:46:33 MST 2012 > > dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC > >argon:~$
Re: bad 5.1 package of poptop
Oops! I forgot to say it's amd64. Thanks. On 05/26/12 16:06, Tobias Ulmer wrote: On Sat, May 26, 2012 at 02:31:52PM +0200, Federico Giannici wrote: The 5.1 package of poptop "poptop-1.3.4p3.tgz" (taken from 2 different official FTP sites) seems to be compiled for a platform after 5.1. If I try to install it an error appears about a c library version not present: # pkg_add poptop-1.3.4p3.tgz Can't install poptop-1.3.4p3 because of libraries |library c.64.1 not found | /usr/lib/libc.so.50.1 (system): bad major | /usr/lib/libc.so.60.1 (system): bad major | /usr/lib/libc.so.51.0 (system): bad major | /usr/lib/libc.so.53.1 (system): bad major | /usr/lib/libc.so.56.0 (system): bad major | /usr/lib/libc.so.62.0 (system): bad major If I force the install, the ldd command confirm the problem: /usr/local/sbin# ldd ./pptpd ./pptpd: ./pptpd: can't load library 'libc.so.64.1' ./pptpd: exit status 4 Thanks. On which architecture? I can observe no such problem: argon:~$ echo $PKG_PATH http://ftp.eu.openbsd.org/pub/OpenBSD/5.1/packages/i386/ argon:~$ sudo pkg_add -i poptop poptop-1.3.4p3: ok The following new rcscripts were installed: /etc/rc.d/pptpd See rc.d(8) for details. Look in /usr/local/share/doc/pkg-readmes for extra documentation. argon:~$ ldd `which pptpd` /usr/local/sbin/pptpd: StartEnd Type Open Ref GrpRef Name 1c00 3c004000 exe 10 0 /usr/local/sbin/pptpd 0b939000 2b967000 rlib 01 0 /usr/lib/libc.so.62.0 08d4 08d4 rtld 01 0 /usr/libexec/ld.so argon:~$ dmesg|sed 2q OpenBSD 5.1 (GENERIC) #160: Sun Feb 12 09:46:33 MST 2012 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC argon:~$
Re: your mail
Jan Stary [h...@stare.cz] wrote: > The "Passing Traffic" example at > http://www.openbsd.org/faq/pf/filter.html > doesn't seem to be completely accurate. > > # Pass traffic in on dc0 from the local network, 192.168.0.0/24, > # to the OpenBSD machine's IP address 192.168.0.1. Also, pass the > # return traffic out on dc0. > pass in on dc0 from 192.168.0.0/24 to 192.168.0.1 > pass out on dc0 from 192.168.0.1 to 192.168.0.0/24 > > It's the "return" that bugs me: the first rule alone > makes the _return_ traffic be passed. The second > rule allows traffic that originates (creates state) > on the way out. Right? Yeah, that sounds right. When the example was written, "keep state flags S/SA" was not a default setting, now it is.
Re: bad 5.1 package of poptop
On Sat, May 26, 2012 at 02:31:52PM +0200, Federico Giannici wrote: > The 5.1 package of poptop "poptop-1.3.4p3.tgz" (taken from 2 > different official FTP sites) seems to be compiled for a platform > after 5.1. > > If I try to install it an error appears about a c library version > not present: > > # pkg_add poptop-1.3.4p3.tgz > Can't install poptop-1.3.4p3 because of libraries > |library c.64.1 not found > | /usr/lib/libc.so.50.1 (system): bad major > | /usr/lib/libc.so.60.1 (system): bad major > | /usr/lib/libc.so.51.0 (system): bad major > | /usr/lib/libc.so.53.1 (system): bad major > | /usr/lib/libc.so.56.0 (system): bad major > | /usr/lib/libc.so.62.0 (system): bad major > > > If I force the install, the ldd command confirm the problem: > > /usr/local/sbin# ldd ./pptpd > ./pptpd: > ./pptpd: can't load library 'libc.so.64.1' > ./pptpd: exit status 4 > > > Thanks. > On which architecture? I can observe no such problem: argon:~$ echo $PKG_PATH http://ftp.eu.openbsd.org/pub/OpenBSD/5.1/packages/i386/ argon:~$ sudo pkg_add -i poptop poptop-1.3.4p3: ok The following new rcscripts were installed: /etc/rc.d/pptpd See rc.d(8) for details. Look in /usr/local/share/doc/pkg-readmes for extra documentation. argon:~$ ldd `which pptpd` /usr/local/sbin/pptpd: StartEnd Type Open Ref GrpRef Name 1c00 3c004000 exe 10 0 /usr/local/sbin/pptpd 0b939000 2b967000 rlib 01 0 /usr/lib/libc.so.62.0 08d4 08d4 rtld 01 0 /usr/libexec/ld.so argon:~$ dmesg|sed 2q OpenBSD 5.1 (GENERIC) #160: Sun Feb 12 09:46:33 MST 2012 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC argon:~$
Re: pf faq
On May 26 12:30:25, Stuart Henderson wrote: > On 2012-05-26, Jan Stary wrote: > > The "Passing Traffic" example at > > http://www.openbsd.org/faq/pf/filter.html > > doesn't seem to be completely accurate. > > > > # Pass traffic in on dc0 from the local network, 192.168.0.0/24, > > # to the OpenBSD machine's IP address 192.168.0.1. Also, pass the > > # return traffic out on dc0. > > pass in on dc0 from 192.168.0.0/24 to 192.168.0.1 > > pass out on dc0 from 192.168.0.1 to 192.168.0.0/24 > > > > It's the "return" that bugs me: the first rule alone > > makes the _return_ traffic be passed. The second > > rule allows traffic that originates (creates state) > > on the way out. Right? > > > > > Probably an incomplete conversion of the faq when the default was changed > to stateful. Exactyl. > If someone wants to carefully go over faq/pf/ (or at least going > over one whole page rather than just parts of a page), check/update things > and send a diff, that would be very nice and there's a good chance it would > get committed.. Actually, I came across this when re-reading the whole PF FAQ earlier today (but I couldn't say carefully); diff below. Jan --- filter.html.orig2012-05-26 15:15:13.0 +0200 +++ filter.html 2012-05-26 15:17:28.0 +0200 @@ -289,12 +289,10 @@ recommended because it errs on the side writing a ruleset easier. -To create a default deny filter policy, the first two filter rules should -be: +To create a default deny filter policy, the first filter rule should be: -block in all -block out all +block all @@ -317,10 +315,9 @@ Some examples: # Pass traffic in on dc0 from the local network, 192.168.0.0/24, -# to the OpenBSD machine's IP address 192.168.0.1. Also, pass the -# return traffic out on dc0. -pass in on dc0 from 192.168.0.0/24 to 192.168.0.1 -pass out on dc0 from 192.168.0.1 to 192.168.0.0/24 +# to the OpenBSD machine's IP address 192.168.0.1. The return traffic +# gets passed too, thanks to statefull operation. +pass in on dc0 from 192.168.0.0/24 to 192.168.0.1 # Pass TCP traffic in on fxp0 to the web server running on the
bad 5.1 package of poptop
The 5.1 package of poptop "poptop-1.3.4p3.tgz" (taken from 2 different official FTP sites) seems to be compiled for a platform after 5.1. If I try to install it an error appears about a c library version not present: # pkg_add poptop-1.3.4p3.tgz Can't install poptop-1.3.4p3 because of libraries |library c.64.1 not found | /usr/lib/libc.so.50.1 (system): bad major | /usr/lib/libc.so.60.1 (system): bad major | /usr/lib/libc.so.51.0 (system): bad major | /usr/lib/libc.so.53.1 (system): bad major | /usr/lib/libc.so.56.0 (system): bad major | /usr/lib/libc.so.62.0 (system): bad major If I force the install, the ldd command confirm the problem: /usr/local/sbin# ldd ./pptpd ./pptpd: ./pptpd: can't load library 'libc.so.64.1' ./pptpd: exit status 4 Thanks.
pf faq [was Re: (unknown)]
On 2012-05-26, Jan Stary wrote: > The "Passing Traffic" example at > http://www.openbsd.org/faq/pf/filter.html > doesn't seem to be completely accurate. > > # Pass traffic in on dc0 from the local network, 192.168.0.0/24, > # to the OpenBSD machine's IP address 192.168.0.1. Also, pass the > # return traffic out on dc0. > pass in on dc0 from 192.168.0.0/24 to 192.168.0.1 > pass out on dc0 from 192.168.0.1 to 192.168.0.0/24 > > It's the "return" that bugs me: the first rule alone > makes the _return_ traffic be passed. The second > rule allows traffic that originates (creates state) > on the way out. Right? > > Probably an incomplete conversion of the faq when the default was changed to stateful. If someone wants to carefully go over faq/pf/ (or at least going over one whole page rather than just parts of a page), check/update things and send a diff, that would be very nice and there's a good chance it would get committed..
Re: openups
On 2012-05-26, bofh wrote: > Have anyone seen this? I just saw it, and even though there's only > windows app available right now, I'm hoping this can tickle some > developer's fancy :) > > http://www.mini-box.com/OpenUPS Might be interesting to have USB UPS report as a sensor for some simple sensorsd-based shutdown control... (but if that's done it would be useful if libusb can still access them, or at least forcibly detach them from the driver at runtime, so people don't need kernel changes to run things like NUT if they prefer that). It might also be interesting for sensorsd to be able to pick up sensors on another machine, with some nice easy syntax if the other machine runs snmpd(8), or some basic support for simple SNMP OID gets to pull data from non-OpenBSD sources (temp sensors on routers/switches etc).
[no subject]
The "Passing Traffic" example at http://www.openbsd.org/faq/pf/filter.html doesn't seem to be completely accurate. # Pass traffic in on dc0 from the local network, 192.168.0.0/24, # to the OpenBSD machine's IP address 192.168.0.1. Also, pass the # return traffic out on dc0. pass in on dc0 from 192.168.0.0/24 to 192.168.0.1 pass out on dc0 from 192.168.0.1 to 192.168.0.0/24 It's the "return" that bugs me: the first rule alone makes the _return_ traffic be passed. The second rule allows traffic that originates (creates state) on the way out. Right?
Re: German Government claims to be able to break PGP and SSH
>Peter Laufenberg wrote: > >> My German's rusty but the follow-up article quoting Symantec mentions >> spyware/keylogging, which has been the traditional "technique" used in >> in the past. > >But that's for targeted surveillance. They still cast a wide net: on ccc.de there's a detailed report of one target wanking to phone-sex. >The original article refers >to a bulk grep of 16,400 search terms over 37 million e-mail messages. I just read the PDF, in 2010 they dumped a raw IP stream from which they extracted individual emails (90% spam) in which they searched for words like "bomb". High-tech stuff. The one-sentence answer about PGP has so many qualifiers that only an idiot would read it as a blanket success claim, the gov official was probably puzzled by the question's "half-pregnant" formulation. Golem seem to have buried their story in an embarrassed rush; whoever came up with the title must be flipping BratwC
Re: Recent BIND ports
On 2012-05-25, Kostas Zorbadelos wrote: > The question is, is there an interest in developing relevant ports? Is > someone working on this? There are searchable mailing list archives, you know...
Re: spamd greylisting: false positives
On 2012-05-25, David Diggles wrote: > I wasn't receiving email, from lists.openbsd.org and also from my > work email address, until I added the respective smtp servers to > the whitelist table in pf. do you have spamlogd running? > Seriously though, if I have to keep manually adding smtp servers > to a whitelist, I will run in blacklist only mode. yes, you do, various large sites use either pools of senders with a shared queue, or senders behind large nats, or bad retry cycles etc. you really need something like the dnswl list (only available by dns lookup for the mos part). one thing that can help is to restrict spamd to only affecting windows hosts (using 'from any os "windows"' in pf rules).
Re: Recent BIND ports
On 2012-05-25, Kostas Zorbadelos wrote: > Henning Brauer writes: > >> * Kostas Zorbadelos [2012-05-25 10:06]: >>> from all relevant discussions I have seen it seems that BIND in base >>> will not be updated to a newer version and unbound has a good chance to >>> be the replacement. The thing is, we need a newer version of BIND for >>> resolving (at least 9.7, preferably 9.8 or in the future 9.9). >> >> purely out of curiosity: why? > > filter--on-v4 (9.7+) (needed now), yes, agreed this is needed, we also want the DNS64 support. I started a port of newer BIND but became unstuck adding back the privsep code we have in BIND in base. Anyone want to help with that or should I just not bother for the port? > stupid NXDOMAIN Redirection > (hopefully we won't need that) (9.9). so sad that this got added. ISC were some of the first and most vocal opponents of this mess when netsol started doing it, even added an option to BIND to filter it per-zone...
