Re: syslog - log program output to its own file
On Mon, 14 Mar 2011 13:07:02 +1300 Paul M wrote: > I have a program who's output I want to log exclusively to it's own > file. > Which is to say I dont want any of it's output appearing in the > system logs. > > Reading the syslog man pages this doesn't seem possible: > If I put > !!myprog > *.* /path/to/logfile > localX, check manpage. i would go with rsyslog seems better. jirib
syslog - log program output to its own file
I have a program who's output I want to log exclusively to it's own file. Which is to say I dont want any of it's output appearing in the system logs. Reading the syslog man pages this doesn't seem possible: If I put !!myprog *.* /path/to/logfile after the initial block (which has no !prog tag), then when the initial block is evaluated and matching entries (based on wildcards) will send output from my program to the system logs. If I put my program tag before the initial block, then the initial block becomes part of the block tagged by !!myprog, so will no longer work as desired. If I put a !* tag after my program block to sepparate the initial block from !!myprog, that undoes the exclusive nature of !!myprog. Perhaps I could do this by using one of the 'local' levels. This would probably work, but would break if some other program used the same local level as me. I see there is syslog-ng which may be more flexible, but I'd rather stick with simply configuring the built in syslogd. If I cant get that to work, I could write my own dedicated logger to only handle my program's output (which would bring other benefits). Is there a way to do this with syslogd? paulm
Re: Upgrading JUST kernel
On 14 March 2011 13:53, Andres Perera wrote: > On Sun, Mar 13, 2011 at 6:43 PM, Joel Wiramu Pauling > wrote: >> Hi all, >> >> in order to fix a hardware problem with 4.8 release I need to move to >> the current or 4.9 kernel. ... > > just after 4.8 was released, ral(4) was patched to work with my card > > i later ended up using -current just as i do know, but for a while i > just identified the patch kindly made by damien@ and applied it to > -stable. it was a very small diff so it worked out just fine > Thanks for all your suggestions. I went through the CVS commits, there are some additional sparc64 patches that look like they will speed up things a lot, as well as my NE card fix so I think I will just do the full upgrade to 4.9-current rather than piecemeal patch based on these recommendations Kind regards -JoelW
Re: Upgrading JUST kernel
> in order to fix a hardware problem with 4.8 release I need to move to > the current or 4.9 kernel. > Having not played around with openbsd's dev trunk before; what is > expected to work/not to work if I just dump in a new bsd kernel and > reboot? > > I quite happily run git built linux kernels willy nilly on older dists > which MOST of the time is fine. Am I going to be safe doing this in > OpenBSD. It is safe. But you are on your own when it breaks, and if you file a bug report which doesn't make that clear, and someone catches you, they'll burn you. As long as you understand those ground rules, enjoy yourself!
Re: Upgrading JUST kernel
On 03/13/11 19:13, Joel Wiramu Pauling wrote: Hi all, in order to fix a hardware problem with 4.8 release I need to move to the current or 4.9 kernel. Having not played around with openbsd's dev trunk before; what is expected to work/not to work if I just dump in a new bsd kernel and reboot? I quite happily run git built linux kernels willy nilly on older dists which MOST of the time is fine. Am I going to be safe doing this in OpenBSD. Kind regards -JoelW Don't do this. Mis-matching the kernel and user-land has unpredictable results. Well, unpredictable in that no one will take the time to figure out what things might not work. I'd suggest jumping to 4.9-current entirely. --STeve Andre'
Re: Upgrading JUST kernel
Expect a system that is deeply and strangely broken, along with accusations of trolling. On Mar 13, 2011, at 6:13 PM, Joel Wiramu Pauling wrote: > Hi all, > > in order to fix a hardware problem with 4.8 release I need to move to > the current or 4.9 kernel. > Having not played around with openbsd's dev trunk before; what is > expected to work/not to work if I just dump in a new bsd kernel and > reboot? > > I quite happily run git built linux kernels willy nilly on older dists > which MOST of the time is fine. Am I going to be safe doing this in > OpenBSD. > > Kind regards > > -JoelW
Upgrading JUST kernel
Hi all, in order to fix a hardware problem with 4.8 release I need to move to the current or 4.9 kernel. Having not played around with openbsd's dev trunk before; what is expected to work/not to work if I just dump in a new bsd kernel and reboot? I quite happily run git built linux kernels willy nilly on older dists which MOST of the time is fine. Am I going to be safe doing this in OpenBSD. Kind regards -JoelW
Comunicamos Urgente ao Cliente Santander e Real S/A
- This mail is a HTML mail. Not all elements could be shown in plain text mode. - Documento sem tmtulo Prezado Cliente: O motivo pelo qual estamos entrando em contato i para alertar que seu Cartco Chave de Seguranga Real-Santander esta EXPIRADO .., Caso nco efetue o seu recadastramento com urgjncia o acesso via Caixas-Eletrtnicos e Internet-Banking ficara SUSPENSO e seu Cartco junto com Chaves de seguranga serco CANCELADOS , impossibilitando acessos e movimentagues. Clique no link abaixo para realizar o recadastramento : Atualizar dados - Real/Santander A atualizagco i obrigatsria para todos os clientes, caso a atualizagco nco seja realizada num prazo de 72 horas o cliente tera a conta suspensa ao acesso Internet Banking Santander, e a mesma ss sera liberada na agjncia de origem. ) 2011 Santander Bank S.A. Todos os direitos reservados.
Re: IPv6 woes: gateway on different subnet
Have you tried ping6 -n ff02::2%re0 ? Does anyone respond? Try using the respond(ers) as your IPv6 default gateway. Link local is best for IPv6 gateways for various reasons, if your upstream isn't picky (unlike he.net tunnels, for example). Penned by Moritz Grimm on 20110313 6:43.32, we have: | Hi, | | | after a couple of days of running into dead ends, I would appreciate | some help. | | To summarize: For more than 3 years I'm successfully running OpenBSD | (it's now at OPENBSD_4_9/i386, running GENERIC.MP) at the German hoster | Hetzner as my expensive little plaything. They offer native IPv6 for | some time now, and I want to use it. However, the same methodology used | with IPv4 does not work with IPv6 and I just can't figure out why (it's | supposed to work identically.) | | | The working IPv4 setup: | | Additional network is 78.47.124.160/29, the gateway is 78.46.41.129/27. | In /etc/hostname.re0 is the aliases and the route to the gateway of that | network: | | inet alias 78.47.124.161 255.255.255.248 78.47.124.167 | [...] | !route add -inet -iface -ifp re0 -net 78.46.41.128 78.46.41.129 -netmask | 255.255.255.224 | | I set the default gateway 78.46.41.129 in the first line of /etc/mygate. | This works: | | $ ping -I 78.47.124.161 www.google.com | PING www.l.google.com (74.125.77.147): 56 data bytes | 64 bytes from 74.125.77.147: icmp_seq=0 ttl=56 time=16.943 ms | [...] | | | The IPv6 setup (broken): | | The IPv6 network is supposed to be 2a01:4f8:110:4363::/64, the gateway | is 2a01:4f8:110:4360::1/59. So again there's the aliases in | /etc/hostname.re0 ... | | [...] | inet6 alias 2a01:4f8:110:4363::42 64 | [...] | !route add -inet6 -iface -ifp re0 -net 2a01:4f8:110:4360:: -prefixlen 59 | 2a01:4f8:110:4360::1 | | The second line in /etc/mygate sets the IPv6 default gateway | 2a01:4f8:110:4360::1. This does not work: | | $ ping6 ipv6.google.com | PING6(56=40+8+8 bytes) 2a01:4f8:110:4363::42 --> 2a00:1450:8005::68 | ping6: sendmsg: No route to host | ping6: wrote ipv6.l.google.com 16 chars, ret=-1 | | | A look at the routing table shows various differences between IPv4 and | IPv6. Again, the working IPv4 entries first: | | default 78.46.41.129 UGS 19 6792145 - 8 re0 | 78.46.41.128/27 link#1 UC2 0 - 4 re0 | 78.46.41.128/27 link#1 UCS 0 0 - 8 re0 | 78.46.41.129 00:26:88:76:21:1b UHLc 1 0 - 4 re0 | 78.46.41.142 00:1d:92:39:57:54 UHLc 0 6 - 4 lo0 | 78.47.124.160/29 link#1 UC0 0 - 4 re0 | 78.47.124.161 127.0.0.1 UGHS 097 33200 8 lo0 | | (.142 is the main IP of mrsserver.net) | | As can be seen, everything resolves nicely ... by comparison, IPv6 looks | fubar'd: | | default 2a01:4f8:110:4360::1 UGS 0 11 - 8 re0 | 2a01:4f8:110:4360::/59 2a01:4f8:110:4360::1 US 1 0 - 8 re0 | 2a01:4f8:110:4363::/64 link#1UC 0 0 - 4 re0 | 2a01:4f8:110:4363::42 00:1d:92:39:57:54 HL 0 0 - 4 lo0 | | That's it, nothing else from these networks, and the local host route | for ::42 isn't even (U)p. | | ndp -a shows: | | Neighbor Linklayer Address Netif ExpireS Flags | 2a01:4f8:110:4363::42 0:1d:92:39:57:54 re0 permanent R | fe80::21d:92ff:fe39:5754%re0 0:1d:92:39:57:54 re0 permanent R | fe80::1%lo0 (incomplete) lo0 permanent R | | I tried to use ndp -I to set the default IPv6 interface to re0, but what | that does is change the behavior of ping6 from EHOSTUNREACH to 100% | packet loss. After doing so, the gateway shows up in ndp: | | 2a01:4f8:110:4360::1 (incomplete) re0 permanent I | | ... and that's as far as I have come. I also tried to solicit router | information after setting net.inet6.ip6.accept_rtadv to 1, but there's | nothing like that on the wire. I have to do manual configuration. | | Lastly, the host's pf.conf is family-agnostic in almost all parts (and | the two remaining places have been triple-checked.) It's also creating | state for all outgoing traffic, so it really shouldn't interfere. | | What I haven't pursued, yet, is that Hetzner configured my network | wrong. This is hard to believe, though, as getting an IPv6 subnet from | them is 100% automated and a problem would probably affect all their | customers. | | I'm stumped. What have I missed? Any and all help is greatly appreciated! | | | Thanks, | | Moritz -- Todd Fries .. t...@fries.net _ | \ 1.636.410.0632 (voice) | Free Daemon Consulting, LLC \ 1.405.227.9094 (voice) | http://FreeDaemonConsulting.com \ 1.866.792.3418 (FAX) | 2525 NW Expy #525, Oklahoma City, OK 73112 \ sip:freedae...@
Re: IPv6 woes: gateway on different subnet
On Sun, 13 Mar 2011 13:45:57 +, FRLinux wrote: >Try this: tracepath6 2a01:4f8:110:4360::1 Wrong mailing list. *** NOTE *** Please DO NOT CC me. I subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it.
Re: quick nfs question: r/w issues on different disk
On Sun, Mar 13, 2011 at 06:40:56PM +, Edd Barrett wrote: > /dev/wd0a on / type ffs (NFS exported, local) Wahh. Bad! -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Votre compte d'acces a ete limite
RC)solution Centre: Votre compte d'accC)s C C)tC) limitC). Nous avions restaurC( l'acces C votre compte. nous avons maintenant besoin que vous confirmez C nouveau Les informations de votre compte chez caisse-epargne.fr veuillez suivre les C(tapes suivants : 1:Cliquez sur le lien ci-dessous pour ouvrir une fenetre Securiser. 2:Confirmez que vous etes le titulaire du Compte,puis suivez les instructions. Cliquez ici pour supprimer la limitation Merci Pour Votre Utilisation de Caisse d'Epargne L'C)quipe Caisse d'Epargne ___ Caisse d'Epargne Email ID: PP 5423
quick nfs question: r/w issues on different disk
Hi, I have here an NFS server which will only serve up read-write exports when they are on /dev/wd0a. I tried for ages to serve up a path under /vol/tomb (which is on /dev/wd1b) and clients are told the fs is read-only upon attempting to write. Serving up from /nports is fine. /nports -alldirs -mapall=edd:users -network=192.168.1 -mask=255.255.255.0 /dev/wd0a on / type ffs (NFS exported, local) /dev/wd0d on /home type ffs (local, nodev, nosuid) /dev/wd1b on /vol/tomb type ffs (NFS exported, local, nodev, nosuid) Why would this be? I can't see anything in the exports manual page regarding nodev or nosuid. I am sure I have served up nfs from >1 disk on the same system before... Or maybe not. Odd. -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Support for ralink rt2760, rt3060
Hi, Is there a support for these chipsets for OpenBSD 4.8/i386? As I understand the documentation the ral driver supports rt2760 (am I right?) but what about rt3060? Thanks in advance, Piotr
Re: IPv6 woes: gateway on different subnet
Hi, > Have you tried pinging the local interface first? Does ping ::1 works? > Then does ping fe80:xxx (replace by output of your interface) works? > etc... Ping6ing those two works. >> The IPv6 network is supposed to be 2a01:4f8:110:4363::/64, the gateway >> is 2a01:4f8:110:4360::1/59. So again there's the aliases in >> /etc/hostname.re0 ... > > Can you ping the gateway? Nope. Not from the server, anyway ... I can ping6 it here from home through my 6in4 tunnel. > Also, showing us a full ifconfig might be good. Here you go. The unabridged ifconfig re0 output: re0: flags=8843 mtu 1500 lladdr 00:1d:92:39:57:54 priority: 0 groups: egress media: Ethernet autoselect (100baseTX full-duplex) status: active inet 78.46.41.142 netmask 0xffe0 broadcast 78.46.41.159 inet6 fe80::21d:92ff:fe39:5754%re0 prefixlen 64 scopeid 0x1 inet 78.47.124.161 netmask 0xfff8 broadcast 78.47.124.167 inet 78.47.124.162 netmask 0xfff8 broadcast 78.47.124.167 inet 78.47.124.163 netmask 0xfff8 broadcast 78.47.124.167 inet 78.47.124.164 netmask 0xfff8 broadcast 78.47.124.167 inet 78.47.124.165 netmask 0xfff8 broadcast 78.47.124.167 inet 78.47.124.166 netmask 0xfff8 broadcast 78.47.124.167 inet6 2a01:4f8:110:4363::2 prefixlen 64 inet6 2a01:4f8:110:4363::3 prefixlen 64 inet6 2a01:4f8:110:4363::4 prefixlen 64 inet6 2a01:4f8:110:4363::5 prefixlen 64 inet6 2a01:4f8:110:4363::6 prefixlen 64 inet6 2a01:4f8:110:4363::7 prefixlen 64 inet6 2a01:4f8:110:4363::42 prefixlen 64 >> inet6 alias 2a01:4f8:110:4363::42 64 > > How did you assign this? Did they or did you? I did, via ifconfig/hostname.if. All of this requires 100% manual configuration. >> !route add -inet6 -iface -ifp re0 -net 2a01:4f8:110:4360:: -prefixlen 59 >> 2a01:4f8:110:4360::1 > > Same question here, if they are using ra, i doubt your routing > gateway will actually be 2a01, more likely to be fe80: If by ra you mean rtadv, i.e. router advertisement, they're explicitly not using/offering it. > Start with internal diagnosis first, then worry about reaching the > outside world. Heh. :) Well, yeah. Purely local IPv6 works, and the sane tunnel setup I have here at home does, too. > Try this: tracepath6 2a01:4f8:110:4360::1 Not sure what that is, but traceroute6 has no chance on mrsserver. The interface-bound route seems to be defunct. Again, works fine through my home tunnel. Thanks for looking into this. Moritz
Re: IPv6 woes: gateway on different subnet
Hello Moritz, On Sun, Mar 13, 2011 at 11:43 AM, Moritz Grimm wrote: > The IPv6 setup (broken): Have you tried pinging the local interface first? Does ping ::1 works? Then does ping fe80:xxx (replace by output of your interface) works? etc... > The IPv6 network is supposed to be 2a01:4f8:110:4363::/64, the gateway > is 2a01:4f8:110:4360::1/59. So again there's the aliases in > /etc/hostname.re0 ... Can you ping the gateway? Also, showing us a full ifconfig might be good. > inet6 alias 2a01:4f8:110:4363::42 64 How did you assign this? Did they or did you? > !route add -inet6 -iface -ifp re0 -net 2a01:4f8:110:4360:: -prefixlen 59 > 2a01:4f8:110:4360::1 Same question here, if they are using ra, i doubt your routing gateway will actually be 2a01, more likely to be fe80: > $ ping6 ipv6.google.com Start with internal diagnosis first, then worry about reaching the outside world. Try this: tracepath6 2a01:4f8:110:4360::1 In my case, the trace reached with a final result of: 2a01:4f8:110:4360::1 56.566ms reached Resume: pmtu 1480 hops 13 back 50 Whereas your assigned IP (2a01:4f8:110:4363::42) did not. Cheers, Steph
Vendor supporting OSS developers with hardware
Hiya, I came across this & thought be of interest to developers (I am not affiliated with the vendor) Gooze are offering smartcards or OTP tokens for open source developers for free in return for improvement of support to security devices If anyone is interested, more details are available at http://www.gooze.eu/feitian-pki-free-software-developer-card Regards Sevan / Venture37
Re: network bandwith with em(4)
Hello I have couple of old ProLiants with bxp/em interfaces with 4.8 stable. If you provide me more info what to test extactly and what output to send, I'd gladly help. BR Peter On 13 Mar 2011 03:56, "Ryan McBride" wrote: > On Sat, Mar 12, 2011 at 06:29:42PM -0800, Chris Cappuccio wrote: >> > Are you suggesting that because you have a quad-port gig nic, your box >> > should be able to do 6 *million* packets per second? By that logic my >> > 5-port Soekris net4801 should be able to handle 740kpps. (for reference, >> > the net4801 does about 3kpps with 4.9) >> >> are you sure? that seems low, the 4501 used to do 4kpps with openbsd 3.3 ! > > Quite sure, though I certainly welcome someone else doing independent > testing to prove me wrong. (FWIW: I tested 3.3 last month and got a > maximum of 2400pps before packet loss exceeded 1%) > > The numbers above are for IP forwarding (not bridging), no PF, TCP syn > packets with random ports, ISN, and source address, but fixed > destination address. Measurements are on either side of the device > using SNMP on the switch, and they match very closely what I'm seeing > from the endpoints on either side of the firewall. The results are also > stable across the more than 30,000 individual tests I've run to date > against a variety of hardware and versions (automated, of course!) > > Note that If you measure on the box itself (i.e. the IPKTS/OPKTS) you > will get lies when the system is livelocking. If you push harder you can > get more packets through the soekris but it's meaningless as most of the > packets are being dropped and the box is completely livelocked.
Re: IPv6 woes: gateway on different subnet
Additional information I forgot previous writeup: at some point in the current setup, the kernel complains. I have one additional line in my dmesg nd6_rtrequest: bad gateway value: re0 Googling this didn't steer me in the right direction. It's also the only error message I'm getting here. Moritz
IPv6 woes: gateway on different subnet
Hi, after a couple of days of running into dead ends, I would appreciate some help. To summarize: For more than 3 years I'm successfully running OpenBSD (it's now at OPENBSD_4_9/i386, running GENERIC.MP) at the German hoster Hetzner as my expensive little plaything. They offer native IPv6 for some time now, and I want to use it. However, the same methodology used with IPv4 does not work with IPv6 and I just can't figure out why (it's supposed to work identically.) The working IPv4 setup: Additional network is 78.47.124.160/29, the gateway is 78.46.41.129/27. In /etc/hostname.re0 is the aliases and the route to the gateway of that network: inet alias 78.47.124.161 255.255.255.248 78.47.124.167 [...] !route add -inet -iface -ifp re0 -net 78.46.41.128 78.46.41.129 -netmask 255.255.255.224 I set the default gateway 78.46.41.129 in the first line of /etc/mygate. This works: $ ping -I 78.47.124.161 www.google.com PING www.l.google.com (74.125.77.147): 56 data bytes 64 bytes from 74.125.77.147: icmp_seq=0 ttl=56 time=16.943 ms [...] The IPv6 setup (broken): The IPv6 network is supposed to be 2a01:4f8:110:4363::/64, the gateway is 2a01:4f8:110:4360::1/59. So again there's the aliases in /etc/hostname.re0 ... [...] inet6 alias 2a01:4f8:110:4363::42 64 [...] !route add -inet6 -iface -ifp re0 -net 2a01:4f8:110:4360:: -prefixlen 59 2a01:4f8:110:4360::1 The second line in /etc/mygate sets the IPv6 default gateway 2a01:4f8:110:4360::1. This does not work: $ ping6 ipv6.google.com PING6(56=40+8+8 bytes) 2a01:4f8:110:4363::42 --> 2a00:1450:8005::68 ping6: sendmsg: No route to host ping6: wrote ipv6.l.google.com 16 chars, ret=-1 A look at the routing table shows various differences between IPv4 and IPv6. Again, the working IPv4 entries first: default 78.46.41.129 UGS 19 6792145 - 8 re0 78.46.41.128/27 link#1 UC2 0 - 4 re0 78.46.41.128/27 link#1 UCS 0 0 - 8 re0 78.46.41.129 00:26:88:76:21:1b UHLc 1 0 - 4 re0 78.46.41.142 00:1d:92:39:57:54 UHLc 0 6 - 4 lo0 78.47.124.160/29 link#1 UC0 0 - 4 re0 78.47.124.161 127.0.0.1 UGHS 097 33200 8 lo0 (.142 is the main IP of mrsserver.net) As can be seen, everything resolves nicely ... by comparison, IPv6 looks fubar'd: default 2a01:4f8:110:4360::1 UGS 0 11 - 8 re0 2a01:4f8:110:4360::/59 2a01:4f8:110:4360::1 US 1 0 - 8 re0 2a01:4f8:110:4363::/64 link#1UC 0 0 - 4 re0 2a01:4f8:110:4363::42 00:1d:92:39:57:54 HL 0 0 - 4 lo0 That's it, nothing else from these networks, and the local host route for ::42 isn't even (U)p. ndp -a shows: Neighbor Linklayer Address Netif ExpireS Flags 2a01:4f8:110:4363::42 0:1d:92:39:57:54 re0 permanent R fe80::21d:92ff:fe39:5754%re0 0:1d:92:39:57:54 re0 permanent R fe80::1%lo0 (incomplete) lo0 permanent R I tried to use ndp -I to set the default IPv6 interface to re0, but what that does is change the behavior of ping6 from EHOSTUNREACH to 100% packet loss. After doing so, the gateway shows up in ndp: 2a01:4f8:110:4360::1 (incomplete) re0 permanent I ... and that's as far as I have come. I also tried to solicit router information after setting net.inet6.ip6.accept_rtadv to 1, but there's nothing like that on the wire. I have to do manual configuration. Lastly, the host's pf.conf is family-agnostic in almost all parts (and the two remaining places have been triple-checked.) It's also creating state for all outgoing traffic, so it really shouldn't interfere. What I haven't pursued, yet, is that Hetzner configured my network wrong. This is hard to believe, though, as getting an IPv6 subnet from them is 100% automated and a problem would probably affect all their customers. I'm stumped. What have I missed? Any and all help is greatly appreciated! Thanks, Moritz
Re: more pf strangeness
An update... > Feb 16 16:44:38.484106 rule def/(short) [uid 0, pid 0] pass > out on xl2: fie.fue.com.5 > 172.24.44.89.0: [udp sum ok] > udp 16 (DF) (ttl 43, id 0, len 44, bad cksum a33e! differs by 100) > > So for some reason I see a misformed, short packet going *out* > of the firewall, but not coming in. Even changing network cards (from xl to re) didn't change the situation - still seeing "(short)" packets logged going out (but not coming in). Julf
