Re: weird PF behavior
* Martin Gignac [EMAIL PROTECTED] [2007-03-15 02:37]: I think this can be explained by the default state policy (which is floating) in pf. Consult the man page and look for 'set state-policy'. do everything else but that. really. this is never ever your problem, except you do weird things with tunnels or the like. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
Re: problem with locate
On Thu, 15 Mar 2007, Han Boetes wrote: Hi, Thanks for your suggestions. Here is what I found. Please let me know if you need more information. This error happens only with the /mnt/mp3 filesystem. Just to make sure it was not a filesystem inconsistency I fsck'ed it. It turned out to be fine. This is what mount returns: /dev/wd1a on /mnt/mp3 type ffs (NFS exported, local, noatime, nodev, nosuid, softdep) And the df output: ~% df -h /mnt/mp3 Filesystem SizeUsed Avail Capacity Mounted on /dev/wd1a 230G217G2.0G99%/mnt/mp3 To make debugging that a bit easier I did the following: sudo /usr/libexec/locate.updatedb --searchpath=/mnt/mp3/Klassiek/Schoenberg/PelleasundMelisande That should be searchpaths with an s. which also reproduces the bug. The dirtree looks like this: ~% \ls -l /mnt/mp3/Klassiek/Schoenberg/PelleasundMelisande total 108256 -r--r--r-- 1 han nfs 14321130 Oct 7 2003 Schoenberg - Pelleas und Melisande - 01 - Ein wenig bewegt - zogernd.ogg -r--r--r-- 1 han nfs 11406273 Oct 7 2003 Schoenberg - Pelleas und Melisande - 02 - Sehr rasch.ogg -r--r--r-- 1 han nfs 9792736 Oct 7 2003 Schoenberg - Pelleas und Melisande - 03 - Langsam.ogg -r--r--r-- 1 han nfs 19796656 Oct 7 2003 Schoenberg - Pelleas und Melisande - 04 - Sehr langsam.ogg And /var/db/locate.database base64 encoded looks like this: LXVuc2FvZ2hyZ2dlbmVsY2hhc2FuU2UvbS5vem90c3Nzcm5yZ3Azb2VudG5nbmRuYm0ubGxs aWxlbGFrL2lzaW5pZ2llaG9nc2dlZ2V3ZXJlZ2VhZWRlZE1kLmRiZWFtU2NQZU1lTGE0MzIw MS9TL1AvS3dybGJFLQ4vbW50L21wMy9LbGGPaWVrL7Bob5SuhC9QnGxlYXN1bmRNnGlzYW5k ZR4+L1NjaG9lbmKnZyAtILGaqXMgdW5kILJsaYluZGUgLSAwMSAtIEVpbiB3lGlnIGKm qHQgLSB6b4VybmQuo2ceNQAAADIgLSBTZWhyIHJhc2NoLm9nZw4zIC0gs25niYyjZw40IC0g U2VociBsYW5nc68ub2dn I checked the md5 of the file which you get if you save this code to a file and run it through base64 -e and it's the same. I recreated the dir tree here, and I can reproduce your problem. I have to find out if the trouble is in generating the database or reading it. -Otto And here is the final output of gdb locate/run foo. (gdb) fastfind_mmap (pathpart=0xcfbe3b42 foo, paddr=0x7c062077 E-\016/mnt/mp3/Kla\217iek/0ho\224.\204/P\234leasundM\234isande\036, le\ n=167, database=0x62 Address 0x62 out of bounds) at fastfind.c:160 (gdb) check_bigram_char (ch=69) at util.c:63 (gdb) (gdb) fastfind_mmap (pathpart=0xcfbe3b42 foo, paddr=0x7c062077 E-\016/mnt/mp3/Kla\217iek/0ho\224.\204/P\234leasundM\234isande\036, le\ n=167, database=0x45 Address 0x45 out of bounds) at fastfind.c:158 (gdb) (gdb) (gdb) (gdb) check_bigram_char (ch=45) at util.c:63 (gdb) (gdb) fastfind_mmap (pathpart=0xcfbe3b42 foo, paddr=0x7c062079 \016/mnt/mp3/Kla\217iek/0ho\224.\204/P\234leasundM\234isande\036, len=\ 165, database=0x2d Address 0x2d out of bounds) at fastfind.c:160 (gdb) check_bigram_char (ch=14) at util.c:63 (gdb) (gdb) fwrite (buf=0xffee, size=1, count=60, fp=0x3c003700) at /usr/src/lib/libc/stdio/fwrite.c:49 # Han
Re: problem with locate
On Thu, 15 Mar 2007, Otto Moerbeek wrote: On Thu, 15 Mar 2007, Han Boetes wrote: Hi, Thanks for your suggestions. Here is what I found. Please let me know if you need more information. This error happens only with the /mnt/mp3 filesystem. Just to make sure it was not a filesystem inconsistency I fsck'ed it. It turned out to be fine. This is what mount returns: /dev/wd1a on /mnt/mp3 type ffs (NFS exported, local, noatime, nodev, nosuid, softdep) And the df output: ~% df -h /mnt/mp3 Filesystem SizeUsed Avail Capacity Mounted on /dev/wd1a 230G217G2.0G99%/mnt/mp3 To make debugging that a bit easier I did the following: sudo /usr/libexec/locate.updatedb --searchpath=/mnt/mp3/Klassiek/Schoenberg/PelleasundMelisande That should be searchpaths with an s. which also reproduces the bug. The dirtree looks like this: ~% \ls -l /mnt/mp3/Klassiek/Schoenberg/PelleasundMelisande total 108256 -r--r--r-- 1 han nfs 14321130 Oct 7 2003 Schoenberg - Pelleas und Melisande - 01 - Ein wenig bewegt - zogernd.ogg -r--r--r-- 1 han nfs 11406273 Oct 7 2003 Schoenberg - Pelleas und Melisande - 02 - Sehr rasch.ogg -r--r--r-- 1 han nfs 9792736 Oct 7 2003 Schoenberg - Pelleas und Melisande - 03 - Langsam.ogg -r--r--r-- 1 han nfs 19796656 Oct 7 2003 Schoenberg - Pelleas und Melisande - 04 - Sehr langsam.ogg And /var/db/locate.database base64 encoded looks like this: LXVuc2FvZ2hyZ2dlbmVsY2hhc2FuU2UvbS5vem90c3Nzcm5yZ3Azb2VudG5nbmRuYm0ubGxs aWxlbGFrL2lzaW5pZ2llaG9nc2dlZ2V3ZXJlZ2VhZWRlZE1kLmRiZWFtU2NQZU1lTGE0MzIw MS9TL1AvS3dybGJFLQ4vbW50L21wMy9LbGGPaWVrL7Bob5SuhC9QnGxlYXN1bmRNnGlzYW5k ZR4+L1NjaG9lbmKnZyAtILGaqXMgdW5kILJsaYluZGUgLSAwMSAtIEVpbiB3lGlnIGKm qHQgLSB6b4VybmQuo2ceNQAAADIgLSBTZWhyIHJhc2NoLm9nZw4zIC0gs25niYyjZw40IC0g U2VociBsYW5nc68ub2dn I checked the md5 of the file which you get if you save this code to a file and run it through base64 -e and it's the same. I recreated the dir tree here, and I can reproduce your problem. I have to find out if the trouble is in generating the database or reading it. -Otto The problem is here that the amount of data is too little to build a complete bigram table. The situation is detected by the diff below. Did you also experience problems when indexing more files? -Otto Index: locate.code.c === RCS file: /cvs/src/usr.bin/locate/code/locate.code.c,v retrieving revision 1.14 diff -u -p -r1.14 locate.code.c --- locate.code.c 19 Feb 2007 20:01:12 - 1.14 +++ locate.code.c 15 Mar 2007 09:25:18 - @@ -149,6 +149,9 @@ main(int argc, char *argv[]) if (fgets(bigrams, sizeof(bigrams), fp) == NULL) err(1, fgets); + if (strlen(bigrams) != BGBUFSIZE) + errx(1, bigram array too small to build db, index more files); + if (fputs(bigrams, stdout) == EOF) err(1, stdout); (void)fclose(fp);
inet6 buffer overflow
Hi, Reading the security advisory for the ipv6 buffer issue, the workaround is to block inet6 traffic in pf.conf. My default block line is actually: block in on $ext_if Where $ext_if is the net connection (the only network connection the machine is plugged into). Is the rule: block in inet6 Redundant in this case, or should it still be added? Gaby -- Junkets for bunterish lickspittles since 1998! http://www.playr.co.uk/sudoku/ http://weblog.vanhegan.net/
Re: i cannot understand GSSAPI/ SSH(openbsd 4.0): i am desperated
Thank you a lot Mr. Corder. You were, simply put, to the point. On 3/13/07, Ryan Corder [EMAIL PROTECTED] wrote: On Mon, 2007-03-12 at 18:45 -0300, Gustavo Rios wrote: All those are disabled! The fact that it is accepting a password for a users that have no password in passwd file when KerberosAuthentication is setted no is dropping down my hairs. Somebody could help me? read VERY closely. 1) in my experience, if you are using a Heimdal or MIT Kerberos service, then OpenSSH use GSSAPIAuthentication and NOT KerberosAuthentication. 2) make sure that in your login.conf that in auth-defaults: auth=passwd and not auth=krb5-or-pwd otherwise PasswordAuthentication will try Kerberos as well before /etc/passwd. 3) just to be absolutely sure, set all of the following to 'no' and then set to 'yes' just the ones you know that you want to turn on... PasswordAuthentication no ChallengeResponseAuthentication no GSSAPIAuthentication no HostbasedAuthentication no KerberosAuthentication no KerberosOrLocalPasswd no PubkeyAuthentication no most likely, what you are looking for, which is the same thing I use is PasswordAuthentication set to 'yes' and GSSAPIAuthentication set to 'yes' and all others set to 'no'. also, combine this with auth=passwd in /etc/login.conf and you get a system where the users are authenticated against Kerberos but denied otherwise unless the explictely have a password set in /etc/passwd. -- Ryan Corder [EMAIL PROTECTED] Systems Engineer, NovaSys Health LLC. 501-219- ext. 646 [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: inet6 buffer overflow
On Thu, Mar 15, 2007 at 10:26:23AM +, Gaby Vanhegan wrote: Hi, Reading the security advisory for the ipv6 buffer issue, the workaround is to block inet6 traffic in pf.conf. My default block line is actually: block in on $ext_if Where $ext_if is the net connection (the only network connection the machine is plugged into). Is the rule: block in inet6 Redundant in this case, or should it still be added? You need to make sure that all your pass rules are for inet only. block in quick inet6 at the beginning of the rules should do the trick. But remeber that localhost is resolved as ::1. -- :wq Claudio
Re: Will be 4.1 release ready for xen?
carlopmart [EMAIL PROTECTED] writes: Hi all, Somebody knows if 4.1 release will be ready for use as a paravirtualized or fully virtualized guest under xen 3.x? (I know that 4.0 works under xen 3.x, but really with very poor performance including under XenExpress or VirtualIron) I can't find anything about this on 4.1's changelog ... Many thanks. There hasn't been any movement in the source tree toward a port to Xen, although some people have been working in that direction outside the official source tree. //art
Re: carp iface keeps switching to master
On Wed, 14 Mar 2007, Dag Richards wrote: Since reporting this problem I have tried running both systems on one switch, and performed a kernel and userland build from stable. The behavior is unchanged in both cases. help? Am I really that stupid? This was working on 3.9 Dag Richards wrote: Two systems running 4.0 GENERIC#1107 i386 on bge drivers. They are being used as vpn servers They are each jacked to their own cisco 2950. The switches are connected with to each other xover cables. Each host can see the others carp traffic, pf is configured to quick pass carp traffic. both system insists on being master. I can ifconfig the desired slave to backup state but after a couple of seconds it pops back to master. I am using sasync, the tunnels are all up and traffic flows as expected though I think that has more to do with pfsync keeping the state tables synced, and the internal interfaces are behaving correctly. The inside ifaces are jacked into the same switch, but shouldn't I be able to be jacked into two separate switches? Erm ... ? I am in GMT + 8, tomorrow morning I will try putting the slave on the same switch as master, but that or course creates a single point of failure. Any other hints? Your two carp interfaces should have the exact same address list, otherwise their hash won't match and the two carp interfaces will both be independent. Add the 10.120.10.2 alias on the slave and your problem will likely disappear. -Otto PS: camield@ spotted this but I don't see him replying...) dump from should be slave 18:21:16.870759 CARPv2-advertise 36: vhid=33 advbase=1 advskew=200 demote=0 (DF) [tos 0x10] 18:21:16.960298 CARPv2-advertise 36: vhid=33 advbase=1 advskew=10 demote=0 (DF) [tos 0x10] 18:21:18.010311 CARPv2-advertise 36: vhid=33 advbase=1 advskew=10 demote=0 (DF) [tos 0x10] 18:21:18.670753 CARPv2-advertise 36: vhid=33 advbase=1 advskew=200 demote=0 (DF) [tos 0x10] 18:21:19.060327 CARPv2-advertise 36: vhid=33 advbase=1 advskew=10 demote=0 (DF) [tos 0x10] 18:21:20.110341 CARPv2-advertise 36: vhid=33 advbase=1 advskew=10 demote=0 (DF) [tos 0x10] 18:21:20.470750 CARPv2-advertise 36: vhid=33 advbase=1 advskew=200 demote=0 (DF) [tos 0x10] ifconfig on slave carp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:00:5e:00:01:21 carp: MASTER carpdev bge0 vhid 33 advbase 1 advskew 200 groups: carp inet6 fe80::200:5eff:fe00:121%carp0 prefixlen 64 scopeid 0x8 inet 10.120.10.50 netmask 0xff00 broadcast 10.120.10.255 slave:root:/etc #sysctl -a | grep carp net.inet.carp.allow=1 net.inet.carp.preempt=1 net.inet.carp.log=0 net.inet.carp.arpbalance=0 dump from should be master 18:21:16.871448 CARPv2-advertise 36: vhid=33 advbase=1 advskew=200 demote=0 (DF) [tos 0x10] 18:21:16.960692 CARPv2-advertise 36: vhid=33 advbase=1 advskew=10 demote=0 (DF) [tos 0x10] 18:21:18.010696 CARPv2-advertise 36: vhid=33 advbase=1 advskew=10 demote=0 (DF) [tos 0x10] 18:21:18.671396 CARPv2-advertise 36: vhid=33 advbase=1 advskew=200 demote=0 (DF) [tos 0x10] 18:21:19.060686 CARPv2-advertise 36: vhid=33 advbase=1 advskew=10 demote=0 (DF) [tos 0x10] 18:21:20.110681 CARPv2-advertise 36: vhid=33 advbase=1 advskew=10 demote=0 (DF) [tos 0x10] ifconfig on master carp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:00:5e:00:01:21 carp: MASTER carpdev bge0 vhid 33 advbase 1 advskew 10 groups: carp inet6 fe80::200:5eff:fe00:121%carp0 prefixlen 64 scopeid 0x8 inet 10.120.10.50 netmask 0xff00 broadcast 10.120.10.255 inet 10.120.10.2 netmask 0xff00 broadcast 10.120.10.255 master:root:/root #sysctl -a | grep carp net.inet.carp.allow=1 net.inet.carp.preempt=1 net.inet.carp.log=0 net.inet.carp.arpbalance=0
Re: weird PF behavior
On 3/15/07, Henning Brauer [EMAIL PROTECTED] wrote: do everything else but that. really. this is never ever your problem, except you do weird things with tunnels or the like. Gotcha. -Martin -- Suburbia is where the developer bulldozes out the trees, then names the streets after them. --Bill Vaughan
Re: problems with reply-to and carped firewall
On 2007/03/15 12:50, Sebastian Reitenbach wrote: I just found a workaround to my problem that's good, I was thinking of reading your original message, but 100+ chars in a line results in nasty line breaks, making things really difficult to read - wrapping at 72 will get you a wider audience. Hi list, I have a carped firewall cluster which is connected to the internet via a cable interface, and one dsl interface, which is used as the default route. The cable IP address is static, and the dsl IP address is dynamic. On the static IP address the traffic is redirected into the DMZ. The traffic from the Internal lan is sent out via the DSL interface, these are just the users that are surfing. There I do not have a problem, this works well. On the cable interface, I told my provider that the MAC address is the one of the carp IP address. With the rules below, it is possible to communicate from the DMZ to the Internet via the Cable Interface, due to the route-to statement. The route-to ($cable_if $cable_gate) sends out my packets with the MAC address of the carp device, so this works well, as I expect. But when I try to connect to the external $cable_mail_ip, with the second reply-to rule, where I use ($cable_if $cable_gate) then the packets are going into the firewall, to the DMZ host. The DMZ host is answering, and the packets arrive again on the firewall, but then they disappear. I had a tcpdump running on all my interfaces, but they did not showed up anywhere... When I use the commented out reply-to rule ($cable_dev $cable_gate), and do not change anything else, then it is working as expected. I can telnet to the mail ports of the mailer in the DMZ. The only drawback is, that then the MAC address of the physical addresses of the cable_dev is used, but these are filtered at my cable ISP. cable_dev=em0 cable_if=carp0
problems with reply-to and carped firewall
Hi list,
I have a carped firewall cluster which is connected to the internet via a cable
interface,
and one dsl interface, which is used as the default route. The cable IP address
is static,
and the dsl IP address is dynamic. On the static IP address the traffic is
redirected into
the DMZ. The traffic from the Internal lan is sent out via the DSL interface,
these are just
the users that are surfing. There I do not have a problem, this works well. On
the cable
interface, I told my provider that the MAC address is the one of the carp IP
address. With
the rules below, it is possible to communicate from the DMZ to the Internet via
the Cable
Interface, due to the route-to statement. The route-to ($cable_if $cable_gate)
sends out my
packets with the MAC address of the carp device, so this works well, as I
expect. But when I
try to connect to the external $cable_mail_ip, with the second reply-to rule,
where I use
($cable_if $cable_gate) then the packets are going into the firewall, to the DMZ
host. The
DMZ host is answering, and the packets arrive again on the firewall, but then
they disappear.
I had a tcpdump running on all my interfaces, but they did not showed up
anywhere... When I
use the commented out reply-to rule ($cable_dev $cable_gate), and do not change
anything
else, then it is working as expected. I can telnet to the mail ports of the
mailer in the
DMZ. The only drawback is, that then the MAC address of the physical addresses
of the
cable_dev is used, but these are filtered at my cable ISP.
cable_dev=em0
cable_if=carp0
dmz_dev=em1
dmz_if=carp1
dsl_dev=vlan12
dsl_if=carp13
cable_mailer=10.10.10.10
mail_ports={25, 993}
nat on $cable_dev from $dmz_net - $cable_mail_ip
rdr on $cable_dev proto tcp to $cable_mail_ip port $mail_ports - $cable_mailer
block in log all
pass out log all keep state
# allow communication from DMZ to Internet
pass in log on $dmz_dev route-to ($cable_if $cable_gate) proto udp from $dmz_net
to any port
{ 53, 123 } keep state
pass in log on $dmz_dev route-to ($cable_if $cable_gate) proto tcp from $dmz_net
to any port
{ 21, 25, 53, 80, 443 } modulate state flags S/SA
#pass in log on $cable_dev reply-to ($cable_dev $cable_gate) proto tcp from any
to
$cable_mail port $ogo_mail_ports modulate state flags S/SA
pass in log on $cable_dev reply-to ($cable_if $cable_gate) proto tcp from any to
$cable_mail
port $ogo_mail_ports modulate state flags S/SA
I am running OpenBSD 4.0, release. Sorry for cross posting, I am not that sure
whether it
might be a pf problem, or sth. openbsd related, therefore to the two mailing
lists. For me
this looks like a bug how reply-to statements are handled, but maybe I did sth.
wrong?
any comment appreciated.
kind regards
Sebastian
Re: problems with reply-to and carped firewall
Hi, Sebastian Reitenbach [EMAIL PROTECTED] wrote: Hi list, I have a carped firewall cluster which is connected to the internet via a cable interface, and one dsl interface, which is used as the default route. The cable IP address is static, and the dsl IP address is dynamic. On the static IP address the traffic is redirected into the DMZ. The traffic from the Internal lan is sent out via the DSL interface, these are just the users that are surfing. There I do not have a problem, this works well. On the cable interface, I told my provider that the MAC address is the one of the carp IP address. With the rules below, it is possible to communicate from the DMZ to the Internet via the Cable Interface, due to the route-to statement. The route-to ($cable_if $cable_gate) sends out my packets with the MAC address of the carp device, so this works well, as I expect. But when I try to connect to the external $cable_mail_ip, with the second reply-to rule, where I use ($cable_if $cable_gate) then the packets are going into the firewall, to the DMZ host. The DMZ host is answering, and the packets arrive again on the firewall, but then they disappear. I had a tcpdump running on all my interfaces, but they did not showed up anywhere... When I use the commented out reply-to rule ($cable_dev $cable_gate), and do not change anything else, then it is working as expected. I can telnet to the mail ports of the mailer in the DMZ. The only drawback is, that then the MAC address of the physical addresses of the cable_dev is used, but these are filtered at my cable ISP. cable_dev=em0 cable_if=carp0 Hi, I just found a workaround to my problem by setting the lladdr of the external physical interface to the same as the carp IP has, and then it works with the cable_dev statement as expected. Note that I have no IP addresses assigned to the physical interface. Sebastian
Re: problem with locate
Otto Moerbeek wrote: The problem is here that the amount of data is too little to build a complete bigram table. The situation is detected by the diff below. Did you also experience problems when indexing more files? Yes. It's the same error as I get with the complete filesystem. Index: locate.code.c === RCS file: /cvs/src/usr.bin/locate/code/locate.code.c,v retrieving revision 1.14 diff -u -p -r1.14 locate.code.c --- locate.code.c 19 Feb 2007 20:01:12 - 1.14 +++ locate.code.c 15 Mar 2007 09:25:18 - @@ -149,6 +149,9 @@ main(int argc, char *argv[]) if (fgets(bigrams, sizeof(bigrams), fp) == NULL) err(1, fgets); + if (strlen(bigrams) != BGBUFSIZE) + errx(1, bigram array too small to build db, index more files); + if (fputs(bigrams, stdout) == EOF) err(1, stdout); (void)fclose(fp); That patch is probably not exactly what you meant since: % sudo /usr/libexec/locate.updatedb locate.code: bigram array too small to build db, index more files # Han
Re: weird PF behavior
On Thu, 2007-03-15 at 01:39 +, Stuart Henderson wrote:
feed the rule into pfctl -nvf - and see how it's expanded.
basically what you would expect...
$ pfctl -nvf -
pass out on bge0 from inside to { !outside , !llcidr } tagged
INSIDE keep state flags S/SA
pass out on bge0 from inside to ! outside flags S/SA keep state
tagged INSIDE
pass out on bge0 from inside to ! llcidr flags S/SA keep state
tagged INSIDE
^C
$
i'm just a bit baffled by this one considering these are the first and
only 'pass out' rules on my external interface and I'm not using the
'quick' keyword anywhere but on the 'pass in' rule on my internal
interface. so, shouldn't these be getting evaluated?
thanks.
ryanc
--
Ryan Corder [EMAIL PROTECTED]
Systems Engineer, NovaSys Health LLC.
501-219- ext. 646
[demime 1.01d removed an attachment of type application/pgp-signature which had
a name of signature.asc]
Dump(8) not honoring nodump flag
Hi, I have a problem with dump(8). Trying to dump a filesystem with nodump flags on some folders results in these folders been dumped anyway, even on higher level dump and even if I specify -h flag to dump. I'm relatevely new to OpenBSD, but have plenty of experience with FreeBSD and Linux so I'm not so sure it's _my_ error. I've tried both 4.0-release and 4.0-stable, same problem. Unfortunately reading the sources didn't help. Any advice? Thanx, D.
Re: Dump(8) not honoring nodump flag
* [EMAIL PROTECTED] [EMAIL PROTECTED] [2007-03-15 17:03]: Hi, I have a problem with dump(8). Trying to dump a filesystem with nodump flags on some folders results in these folders been dumped anyway, even on higher level dump and even if I specify -h flag to dump. well, how? if you do a full dump you need to use -h 0 for nodump to have any effect. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
Re: Dump(8) not honoring nodump flag
[EMAIL PROTECTED] wrote on 15/03/2007 17:16:34: * [EMAIL PROTECTED] [EMAIL PROTECTED] [2007-03-15 17:03]: Hi, I have a problem with dump(8). Trying to dump a filesystem with nodump flags on some folders results in these folders been dumped anyway, even on higher level dump and even if I specify -h flag to dump. well, how? if you do a full dump you need to use -h 0 for nodump to have any effect. I tried both, dump -0a -h 0 ... and dump -1a ... with and without -h. Same effect, the files under the nodump dir got into the archive. D.
Re: problem with locate
On Thu, 15 Mar 2007, Han Boetes wrote: Otto Moerbeek wrote: The problem is here that the amount of data is too little to build a complete bigram table. The situation is detected by the diff below. Did you also experience problems when indexing more files? Yes. It's the same error as I get with the complete filesystem. Index: locate.code.c === RCS file: /cvs/src/usr.bin/locate/code/locate.code.c,v retrieving revision 1.14 diff -u -p -r1.14 locate.code.c --- locate.code.c 19 Feb 2007 20:01:12 - 1.14 +++ locate.code.c 15 Mar 2007 09:25:18 - @@ -149,6 +149,9 @@ main(int argc, char *argv[]) if (fgets(bigrams, sizeof(bigrams), fp) == NULL) err(1, fgets); + if (strlen(bigrams) != BGBUFSIZE) + errx(1, bigram array too small to build db, index more files); + if (fputs(bigrams, stdout) == EOF) err(1, stdout); (void)fclose(fp); That patch is probably not exactly what you meant since: % sudo /usr/libexec/locate.updatedb locate.code: bigram array too small to build db, index more files Hmm, can you instrument /usr/libexec/locate.updatedb with a tee /tmp/myflist | on line 101 to see the filelist it actualy builds? -Otto
Re: Dump(8) not honoring nodump flag
Antoine Jacoutot [EMAIL PROTECTED] wrote on 15/03/2007 17:16:31: On Thu, 15 Mar 2007, [EMAIL PROTECTED] wrote: Trying to dump a filesystem with nodump flags on some folders results in these folders been dumped anyway, even on higher level dump and even if I Yes, you have to set the nodump flags recursively for all files under those directories. ie. chflags -R nodump /path/to/dir I set this and in fact it works. But that's strange compared to the other BSDs and Linux in which the nodump flags on a directory exclude the entire sub-tree. This also means that every time I want to dump a fs I have to reset the nodump flags for all the files in those directories I don't want to include as newer files won't keep that. Also don't forget the '-h 0' flag fo dump(8) if you don't want any backup at all on those dirs. I'm using this flag, but I didn't expect this non-recursive behaviour of dump. Thank you. D.
Re: Dump(8) not honoring nodump flag
On Thu, 15 Mar 2007, [EMAIL PROTECTED] wrote: Yes, you have to set the nodump flags recursively for all files under those directories. ie. chflags -R nodump /path/to/dir I set this and in fact it works. But that's strange compared to the other BSDs and Linux in which the nodump flags on a directory exclude the entire sub-tree. Yup, well this is not strange, this is just different behaviour ;-) This also means that every time I want to dump a fs I have to reset the nodump flags for all the files in those directories I don't want to include as newer files won't keep that. Yes. -- Antoine
Re: Dump(8) not honoring nodump flag
Antoine Jacoutot [EMAIL PROTECTED] wrote on 15/03/2007 17:52:58: On Thu, 15 Mar 2007, [EMAIL PROTECTED] wrote: Yes, you have to set the nodump flags recursively for all files under those directories. ie. chflags -R nodump /path/to/dir I set this and in fact it works. But that's strange compared to the other BSDs and Linux in which the nodump flags on a directory exclude the entire sub-tree. Yup, well this is not strange, this is just different behaviour ;-) Ok, I can agree with that, but what good the nodump flag is on a directory, than? It serves no purpuse. This also means that every time I want to dump a fs I have to reset the nodump flags for all the files in those directories I don't want to include as newer files won't keep that. Yes. Unconfortable... Thx, D.
sendto: No buffer space available
Hello, I am using an OpenBSD 4.0 box connected to a 2Mbit SDSL line in Germany (using user space PPP). When pinging a host across the SDSL line, I get an occasional sendto: No buffer space available message: 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=566 ttl=254 time=62.674 ms 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=568 ttl=254 time=38.090 ms ping: sendto: No buffer space available ping: wrote xxx.xxx.xx 64 chars, ret=-1 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=569 ttl=254 time=1320.651 ms 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=571 ttl=254 time=35.792 ms Does this message point to a problem within OpenBSD or is this a problem with the SDSL line? Why is the ping packet not simply dropped but rather delayed? I have googled for the error message and some replies indicated that it is a problem within some ethernet card drivers, so I switched from fxp to em but the problem persists. This is the output of netstat -m in case it matters: 443 mbufs in use: 437 mbufs allocated to data 3 mbufs allocated to packet headers 3 mbufs allocated to socket names and addresses 436/552/6144 mbuf clusters in use (current/peak/max) 1248 Kbytes allocated to network (78% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines Any help is greatly appreciated. Regards, -Walter Doerr
Re: sendto: No buffer space available
On Thu, Mar 15, 2007 at 05:42:48PM +0100, Walter Doerr wrote: Hello, I am using an OpenBSD 4.0 box connected to a 2Mbit SDSL line in Germany (using user space PPP). When pinging a host across the SDSL line, I get an occasional sendto: No buffer space available message: 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=566 ttl=254 time=62.674 ms 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=568 ttl=254 time=38.090 ms ping: sendto: No buffer space available ping: wrote xxx.xxx.xx 64 chars, ret=-1 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=569 ttl=254 time=1320.651 ms 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=571 ttl=254 time=35.792 ms Does this message point to a problem within OpenBSD or is this a problem with the SDSL line? Why is the ping packet not simply dropped but rather delayed? I have googled for the error message and some replies indicated that it is a problem within some ethernet card drivers, so I switched from fxp to em but the problem persists. I think I mentionened this already a few times but I'll do it again. sendto: No buffer space available means an ENOBUF error was returned. On modern systems ENOBUF is almost only generated by the interfaces and their queues (e.g. if you enable a too restrictive altq limit). So if you have altq enabled I would look at the pfctl -sq -vv output. I doubt it is the fxp/em card -- your pinging the other side of the SDSL line so the traffic flows first through tun(4). The interface queue on tun(4) can get full because userland ppp fails to read fast enough or blocks for some time. As the ping is delayed by 1 second I think ppp blocked and stopped reading /dev/tun0 for around 1 second. The 1 Mio. Dollar question is why did it block. A possible workaround is to switch to the kernel pppoe(4) version. -- :wq Claudio
[no subject]
Is it safe to install snapshot packages? For installing like K 3.5.6 or gaim 2 beta 6, is it ok? Create and Share your own Video Clip Playlist in minutes at Lycos MIX (http://mix.lycos.com)
Re: Dump(8) not honoring nodump flag
* [EMAIL PROTECTED] [EMAIL PROTECTED] [070315 12:03]: Hi, I have a problem with dump(8). Trying to dump a filesystem with nodump flags on some folders results in these folders been dumped anyway, even on higher level dump and even if I specify -h flag to dump. I'm relatevely new to OpenBSD, but have plenty of experience with FreeBSD and Linux so I'm not so sure it's _my_ error. I've tried both 4.0-release and 4.0-stable, same problem. Unfortunately reading the sources didn't help. Any advice? Thanx, D. Your correct, the nodump flag on directories has no affect on the files within that directory. Both Free and Net have patched their respective versions to change that behaviour. I'm working on a patch. The hold up is digging through restore to make sure I do this correctly. No point in frogging up dumpinomap, dumpdirmap, and usedinomap if restore doesn't do what you expect. Jim
Re:
On 3/15/07, x x [EMAIL PROTECTED] wrote: Is it safe to install snapshot packages? For installing like K 3.5.6 or gaim 2 beta 6, is it ok? They wouldn't be posted as packages if they had huge obvious security holes. Duh. That said, they are snapshots (wait, are you talking about OpenBSD snapshosts or independent-project snapshots?) and the usual you're-on-your-own warning applies. -Nick
Re:
Hey x x, Is it safe to install snapshot packages? For installing like K 3.5.6 or gaim 2 beta 6, is it ok? If you run -current (or a recent snapshot): knock yourself out. If you run any type of -release or -stable: I wouldn't do that if I were you. HTH... Nico
Re:
I on Ok, I'm using 4.0 from the FTP install for the sets, I still have find how to get the ports installed, and wanted to see if, and how, to get K 3.5.6 installed, or should I just use what's ever in the ftp directory for 4.0. -[ Received Mail Content ]-- Subject : Re: Date : Thu, 15 Mar 2007 19:32:33 +0100 From : Nico Meijer To : x x Cc : Hey x x, Is it safe to install snapshot packages? For installing like K 3.5.6 or gaim 2 beta 6, is it ok? If you run -current (or a recent snapshot): knock yourself out. If you run any type of -release or -stable: I wouldn't do that if I were you. HTH... Nico Create and Share your own Video Clip Playlist in minutes at Lycos MIX (http://mix.lycos.com)
Re:
On 3/15/07, x x [EMAIL PROTECTED] wrote: I on Ok, I'm using 4.0 from the FTP install for the sets, I still have find how to get the ports installed, and wanted to see if, and how, to get K 3.5.6 installed, or should I just use what's ever in the ftp directory for 4.0. So you don't even have a system installed yet? Go read http://www.openbsd.org/faq/faq4.html, twice. Once you're set up, run `man pkg_add` and read it. Also, there is no gaim2 port for OpenBSD, as far as I know. You're stuck with gaim1.5 like the rest of us. -Nick
Re: problem with locate
Otto Moerbeek wrote:
Hmm, can you instrument /usr/libexec/locate.updatedb with a
tee /tmp/myflist |
on line 101 to see the filelist it actualy builds?
Sure, I just did that and examined /tmp/myflist and it looks
perfectly normal.
# Han
Re: sendto: No buffer space available
2007/3/15, Claudio Jeker [EMAIL PROTECTED]:
I think I mentionened this already a few times but I'll do it again.
sendto: No buffer space available means an ENOBUF error was returned.
On modern systems ENOBUF is almost only generated by the interfaces and
their queues (e.g. if you enable a too restrictive altq limit).
So if you have altq enabled I would look at the pfctl -sq -vv output.
I have the same problem, but disabling altq doesn't help.
I can easily repeat it: Firewall is a K6/3-400 with 4.0, sis(tun0) and
rl running squid. If the client (Linux 2.6.16 (SUSE 10.1)) runs at
least two downloads with FireFox and DownThemAll, i.e. more than ca. 4
http requests in parallel, the network will stop occasionally, but
recover.
A possible workaround is to switch to the kernel pppoe(4) version.
Which doesn't do everything pppoe(8) does. :-{
Best
Martin
Re: problem with locate
On Thu, 15 Mar 2007, Han Boetes wrote: Otto Moerbeek wrote: Hmm, can you instrument /usr/libexec/locate.updatedb with a tee /tmp/myflist | on line 101 to see the filelist it actualy builds? Sure, I just did that and examined /tmp/myflist and it looks perfectly normal. Can you send it to me so I can process it here and see if it creates a corrupted DB? -Otto
Re: carp iface keeps switching to master
Camiel Dobbelaar wrote: Make sure your addresses are in sync... number of addresses and the netmask are different. On Wed, 14 Mar 2007, Dag Richards wrote: inet 10.120.10.50 netmask 0xff00 broadcast 10.120.10.255 inet 10.120.10.50 netmask 0xff00 broadcast 10.120.10.255 inet 10.120.10.2 netmask 0xff00 broadcast 10.120.10.255 Yup don't know why that netmask was like that as I was snap-shotting my config for posting ... but it is/was not like that as a rule. Anyway it was the magic clue, thanks, master had an address that slave did not. As soon as I synced the config joy and correctness followed. Thanks for the help.
Re:
I have it installed, the sets and that, but no ports or anything. I have to add a user and all that. I don't use my computer for anything on the net right now, want to install KDE so I can do all the net\webmail and music\video stuff I usually do. And for gaim, there's ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/i386/gaim-2.0.0beta6p2.tgz ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/i386/gaim-2.0.0beta6p2-gtkspell.tgz I on Ok, I'm using 4.0 from the FTP install for the sets, I still have find how to get the ports installed, and wanted to see if, and how, to get K 3.5.6 installed, or should I just use what's ever in the ftp directory for 4.0. So you don't even have a system installed yet? Go read http://www.openbsd.org/faq/faq4.html, twice. Once you're set up, run `man pkg_add` and read it. Also, there is no gaim2 port for OpenBSD, as far as I know. You're stuck with gaim1.5 like the rest of us. -Nick Create and Share your own Video Clip Playlist in minutes at Lycos MIX (http://mix.lycos.com)
Re: weird PF behavior
On Thu, 2007-03-15 at 15:32 +, Stuart Henderson wrote:
On 2007/03/15 10:25, Ryan Corder wrote:
On Thu, 2007-03-15 at 01:39 +, Stuart Henderson wrote:
feed the rule into pfctl -nvf - and see how it's expanded.
basically what you would expect...
pass out on bge0 from inside to ! outside ...
pass out on bge0 from inside to ! llcidr ...
i.e.
pass out to everyone-apart-from-outside
pass out to everyone-apart-from-llcidr
This blocks only the intersection of outside and llcidr
(probably nobody).
ok, so I want:
pass out to everyone-except-from-outside
pass out to everyone-except-from-llcidr
would that be:
pass out on bge0 from inside to { any, !outside, !llcidr }
--
Ryan Corder [EMAIL PROTECTED]
Systems Engineer, NovaSys Health LLC.
501-219- ext. 646
[demime 1.01d removed an attachment of type application/pgp-signature which had
a name of signature.asc]
Re: weird PF behavior
On 2007/03/15 16:00, Ryan Corder wrote:
pass out to everyone-apart-from-outside
pass out to everyone-apart-from-llcidr
This blocks only the intersection of outside and llcidr
(probably nobody).
ok, so I want:
pass out to everyone-except-from-outside
pass out to everyone-except-from-llcidr
That's what you're doing now with the { x, y } syntax in a rule,
but it's not what you want: it expands to two fully independent rules,
the first passes almost all traffic from inside, and the second rule
passes almost all traffic from inside.
would that be:
pass out on bge0 from inside to { any, !outside, !llcidr }
No, that would expand to three rules, one passing all traffic from
inside and the other two as above.
you either need:
pass out on bge0 from inside
block out on bge0 from inside to { outside, llcidr }
or:
block quick out on bge0 from inside to { outside, llcidr }
pass out on bge0 from inside
alternatively you could have a combined table containing both
outside and llcidr sets of addresses, but you can't nest tables
so it's probably more work to maintain.
the PF faq has something on the subject (tables.html, macros.html).
Re: problem with locate
On Thu, 15 Mar 2007, Otto Moerbeek wrote:
On Thu, 15 Mar 2007, Han Boetes wrote:
Otto Moerbeek wrote:
Hmm, can you instrument /usr/libexec/locate.updatedb with a
tee /tmp/myflist |
on line 101 to see the filelist it actualy builds?
Sure, I just did that and examined /tmp/myflist and it looks
perfectly normal.
Can you send it to me so I can process it here and see if it creates a
corrupted DB?
I see the problem. The problem occurs if top bigrams contain spaces.
These are not handled correctly by awk. We'll have to use a field
separator that can not be in a bigram. A tab is well suited, AFAKS.
Try this.
-Otto
Index: bigram/locate.bigram.c
===
RCS file: /cvs/src/usr.bin/locate/bigram/locate.bigram.c,v
retrieving revision 1.10
diff -u -p -r1.10 locate.bigram.c
--- bigram/locate.bigram.c 29 Sep 2003 16:03:16 - 1.10
+++ bigram/locate.bigram.c 15 Mar 2007 22:39:30 -
@@ -106,7 +106,7 @@ main(void)
for (i = ASCII_MIN; i = ASCII_MAX; i++)
for (j = ASCII_MIN; j = ASCII_MAX; j++)
if (bigram[i][j] != 0)
- (void)printf(%4u %c%c\n, bigram[i][j], i, j);
+ (void)printf(%4u\t%c%c\n, bigram[i][j], i, j);
exit(0);
}
Index: code/locate.code.c
===
RCS file: /cvs/src/usr.bin/locate/code/locate.code.c,v
retrieving revision 1.14
diff -u -p -r1.14 locate.code.c
--- code/locate.code.c 19 Feb 2007 20:01:12 - 1.14
+++ code/locate.code.c 15 Mar 2007 09:25:18 -
@@ -149,6 +149,9 @@ main(int argc, char *argv[])
if (fgets(bigrams, sizeof(bigrams), fp) == NULL)
err(1, fgets);
+ if (strlen(bigrams) != BGBUFSIZE)
+ errx(1, bigram array too small to build db, index more files);
+
if (fputs(bigrams, stdout) == EOF)
err(1, stdout);
(void)fclose(fp);
Index: locate/mklocatedb.sh
===
RCS file: /cvs/src/usr.bin/locate/locate/mklocatedb.sh,v
retrieving revision 1.12
diff -u -p -r1.12 mklocatedb.sh
--- locate/mklocatedb.sh29 Jun 2003 21:59:28 - 1.12
+++ locate/mklocatedb.sh15 Mar 2007 22:40:27 -
@@ -68,7 +68,7 @@ trap 'rm -f $bigrams $filelist' 0 1 2 3
if $sortcmd $sortopt $filelist; then
$bigram $filelist | $sort -nr |
-awk 'BEGIN { ORS = } NR = 128 { print $2 }' $bigrams
+awk -Ft 'BEGIN { ORS = } NR = 128 { print $2 }' $bigrams
$code $bigrams $filelist
else
echo `basename $0`: cannot build locate database 2
Re: weird PF behavior
On Thu, 2007-03-15 at 22:42 +, Stuart Henderson wrote:
No, that would expand to three rules, one passing all traffic from
inside and the other two as above.
you either need:
pass out on bge0 from inside
block out on bge0 from inside to { outside, llcidr }
or:
block quick out on bge0 from inside to { outside, llcidr }
pass out on bge0 from inside
alright, but I already have a default block everything rule, why would
I need additional block rules?
alternatively you could have a combined table containing both
outside and llcidr sets of addresses, but you can't nest tables
so it's probably more work to maintain.
which is too bad.
alternatively, I did this and it seemed to work
pass out on bge0 from inside to { any, !outside }
pass out on bge0 from inside to { any, !llcidr }
--
Ryan Corder [EMAIL PROTECTED]
Systems Engineer, NovaSys Health LLC.
501-219- ext. 646
[demime 1.01d removed an attachment of type application/pgp-signature which had
a name of signature.asc]
Re: problem with locate
Otto Moerbeek wrote: I see the problem. The problem occurs if top bigrams contain spaces. These are not handled correctly by awk. We'll have to use a field separator that can not be in a bigram. A tab is well suited, AFAKS. Try this. [snip: patch] % sudo /usr/libexec/locate.updatedb --searchpaths=/mnt/mp3 /usr/src/usr.bin/locate% \locate foo /mnt/mp3/4ad/ClanOfXymox/[1991]Phoenix/Clan Of Xymox - Phoenix - 08 - Dancing Barefoot.mp3 /mnt/mp3/Metal/LedZeppelin/Remasters/CD 2/Led Zeppelin - Remasters - 07 - Trampled Underfoot.mp3 /mnt/mp3/Pop/BoudewijndeGroot/Wonderkind_aan_het_Strand/Onderstroom/Boudewijn de Groot - Wonderkind aan het strand CD4 Onderstroom - 05 - De dominee van Amersfoort.ogg /mnt/mp3/Pop/FairportConvention/Fotheringay/Fairport Convention - Fotheringay - 08 - Fotheringay - The Way I Feel(Gordon Lightfoot).mp3 /mnt/mp3/Pop/Nirvana/Incesticide/Nirvana - Incesticide - 11 - Mexican seafood.mp3 Dude! You rock! =) # Han
MetaBUG
No, I'm not talking about a bug in design. Instead, I'm talking about a new organization for new, old, or yet-to-exist *BSD User Groups. See http://undeadly.org/cgi?action=articlesid=20070315164840 and http://metabug.org/ for more info. But in a nutshell we're providing mutual support for BUGs by sharing ideas and resources. One of the first really cool things we're planning is streaming video of BUG presentations, with archives available. Also see the mailing list details at http://metabug.org/mail/ If you're in a BUG, want to start one, or just wish you had one where you lived then check us out. We've got several BUGs on board already and should have more soon! We would very much like to hear from any of you running a BUG! So far, we have participation from CapBUG, GUBUG, ManchesterBUG, OCUUG, and PhxBUG. -- Darrin Chandler | Phoenix BSD Users Group [EMAIL PROTECTED] | http://bsd.phoenix.az.us/ http://www.stilyagin.com/darrin/ |
Re: Important OpenBSD errata
On 03/14/2007 09:13:19 AM, Martin Schrvder wrote: 2007/3/13, Theo de Raadt [EMAIL PROTECTED]: This means everyone should have our latest patches installed. Just a reminder: security-announce exists for messages like this. Use it or delete it. While the bug is bad, the handling of it is even worse. I agree. I'm very annoyed that I have to read about this problem on slashdot. The misc list is not the right place for this announcement, some low-traffic announce list that goes right into my inbox is where this stuff belongs. I rely on having a clear channel for security related problems. OpenBSD's excellent reputation is what allows me to sell it to my clients, which allows me to work with OpenBSD. I've always used the proactive, transparent, and forthright tone of OpenBSD related communication as a selling point. This is the first time I've felt let down and I hope it's the last. I realize we get what we get from the OpenBSD project, and I've certainly gotten a lot more than I've put into it. The response and and announcement latency has always been great, with a low signal to noise ratio. My high expectations have always been met and that's what makes this communication breakdown hurt. It's not the magnitude of the security vulnerability that's the problem. Problems communicating patch availability lead to security problems as severe as unpatched vulnerabilities. Therefore communication problems deserve the degree of acknowledgment and resolution accorded to bugs in the code. Regards, Karl [EMAIL PROTECTED] Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein
Re: Important OpenBSD errata
On Mar 15, 2007, at 7:31 PM, Karl O. Pinc wrote: snip I agree. I'm very annoyed that I have to read about this problem on slashdot. The misc list is not the right place for this announcement, some low-traffic announce list that goes right into my inbox is where this stuff belongs. I rely on having a clear channel for security related problems. You -do- know that this has been on the errata page since Friday, right? Because as worried as you are and as important as this is to you you take the responsibility to check said page every day, of course. Oh wait. No you don't. Come on this is open source it should be a maker's culture. You know where these things are as soon as they hit the tree and it takes all of two whole minutes to glance at it once or twice a day. Step up to the plate and do for yourself. snip Problems communicating patch availability lead to security problems as severe as unpatched vulnerabilities. Therefore communication problems deserve the degree of acknowledgment and resolution accorded to bugs in the code. The only communication problem here is that you don't look at the information that the project puts out there for you. You are correct. This needs to be fixed. Do so. Regards, Karl [EMAIL PROTECTED] Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein They do not preach that their God will rouse them a little before the nuts work loose.
Re: Important OpenBSD errata
On 15-Mar-07, at 11:48 PM, Ray Percival wrote: On Mar 15, 2007, at 7:31 PM, Karl O. Pinc wrote: snip I agree. I'm very annoyed that I have to read about this problem on slashdot. The misc list is not the right place for this announcement, some low-traffic announce list that goes right into my inbox is where this stuff belongs. I rely on having a clear channel for security related problems. You -do- know that this has been on the errata page since Friday, right? Because as worried as you are and as important as this is to you you take the responsibility to check said page every day, of course. Oh wait. No you don't. Come on this is open source it should be a maker's culture. You know where these things are as soon as they hit the tree and it takes all of two whole minutes to glance at it once or twice a day. Step up to the plate and do for yourself. That's what I was going to say. If you did things properly, you would have had this patch applied before you knew that it was a remote hole. I was confused when I read that the patch had been published on the 7th because I didn't think I'd seen it. Then I realized I was already running it. That's called a -6 day bug fix ;) 'Course it seems odd that this isn't on security-announce@ but I don't remember seeing a guarantee of that when I signed the contract... oh wait...
Re: Important OpenBSD errata
Karl O. Pinc wrote: On 03/14/2007 09:13:19 AM, Martin Schrvder wrote: 2007/3/13, Theo de Raadt [EMAIL PROTECTED]: This means everyone should have our latest patches installed. Just a reminder: security-announce exists for messages like this. Use it or delete it. While the bug is bad, the handling of it is even worse. I agree. I'm very annoyed that I have to read about this problem on slashdot. The misc list is not the right place for this announcement, some low-traffic announce list that goes right into my inbox is where this stuff belongs. I rely on having a clear channel for security related problems. OpenBSD's excellent reputation is what allows me to sell it to my clients, which allows me to work with OpenBSD. I've always used the proactive, transparent, and forthright tone of OpenBSD related communication as a selling point. This is the first time I've felt let down and I hope it's the last. I realize we get what we get from the OpenBSD project, and I've certainly gotten a lot more than I've put into it. The response and and announcement latency has always been great, with a low signal to noise ratio. My high expectations have always been met and that's what makes this communication breakdown hurt. It's not the magnitude of the security vulnerability that's the problem. Problems communicating patch availability lead to security problems as severe as unpatched vulnerabilities. Therefore communication problems deserve the degree of acknowledgment and resolution accorded to bugs in the code. Regards, Karl [EMAIL PROTECTED] Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein 1) JUMP! 2) HOW HIGH? Do you REALLY want to play that game? If the security is real and is actually proactive Seems like you shouldn't have to play that game. Is the bug actually serious in practice? Are you actually safer with the bug fixed? My gut feel is that the next unsung fix will actually make more difference to how secure the resulting system is. This is from a kibitzer, BUT I can guarantee that the security of OpenBSD is NOT due to panic attacks of trying to keep up with the latest security breaches.
Re: Important OpenBSD errata
On 03/15/2007 10:24:31 PM, Tony Abernethy wrote: Karl O. Pinc wrote: On 03/14/2007 09:13:19 AM, Martin Schrvder wrote: 2007/3/13, Theo de Raadt [EMAIL PROTECTED]: This means everyone should have our latest patches installed. Just a reminder: security-announce exists for messages like this. Use it or delete it. I rely on having a clear channel for security related problems. My high expectations have always been met and that's what makes this communication breakdown hurt. It's not the magnitude of the security vulnerability that's the problem. Problems communicating patch availability lead to security problems as severe as unpatched vulnerabilities. 1) JUMP! 2) HOW HIGH? If the security is real and is actually proactive Seems like you shouldn't have to play that game. All the security in the world does me no good if it's not installed on my systems. Is the bug actually serious in practice? No. Are you actually safer with the bug fixed? Yes. If I wasn't then there wouldn't be an errata would there? My gut feel is that the next unsung fix will actually make more difference to how secure the resulting system is. I track -STABLE, because I want relyability. I won't get the next unsung fix until an errata is announced that might affect me. I've better things to do than install new builds all the time. This is from a kibitzer, BUT I can guarantee that the security of OpenBSD is NOT due to panic attacks of trying to keep up with the latest security breaches. No, but if security errata announcements arn't delivered in a fashion that delivers them to a human then they do no good. I should not be expected to peruse the misc@openbsd.org list to find errata announcements. OpenBSD says announcements will be made on security-announce when patches become available. This did not happen. Ergo, something is broken. I can't fix it. It may not be fixable, but if it is fixable then it should be fixed. We should not all just pretend it didn't happen. If there is something that can be fixed I'd like to hear about it when it gets fixed. Hence my post. Further, it's important to let the OpenBSD project know how important the brokenness is. (Recall, I'm not talking about the security vulnerability, I'm talking about the communication breakdown.) If my clients hear about a OpenBSD vulnerability from the media, before I hear about it from OpenBSD, that's bad. I want them to hear about problems with their systems, however slight, from me (or directly from OpenBSD of course). I don't want clients to hear about problems on their systems from some media panic attack article. OpenBSD has always solicited feedback regards how important particular bugs are. Now you've the relevant information you can decide how high to jump. Regards, Karl [EMAIL PROTECTED] Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein
Re: Important OpenBSD errata
Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein I was trying to decide if I should reply, and if so, how. I looked for your name on the donations list. I don't see it. But your quote makes it clear. I don't know what to say. I am trying to get past the first impression of you being a whining liar who quotes some fiction author. Give it up. He uses our software, and he's not worth the discussion.
Re: Important OpenBSD errata
On 03/15/2007 10:48:49 PM, Ray Percival wrote: On Mar 15, 2007, at 7:31 PM, Karl O. Pinc wrote: I rely on having a clear channel for security related problems. The only communication problem here is that you don't look at the information that the project puts out there for you. The project says it will announce security errata on the security-announce list. I _am_ assuming this will be done in a timely fashion... This does not seem like an unreasonable assumption. If security-announce is not a place for timely security announcments then change the description, or get rid of it. Which brings the discussion back to where it started, and where it belongs. Karl [EMAIL PROTECTED] Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein
Re: Important OpenBSD errata
On 03/15/2007 11:04:49 PM, Jeremy Huiskamp wrote: That's what I was going to say. If you did things properly, you would have had this patch applied before you knew that it was a remote hole. You have a valid point: any bug is a security problem. However, the topic is not my management practices and the tradeoffs involved therein. The topic is the efficacy of the security-announce list. If I knew security-announce was broken I could write a screen-scraper to check the errata page for me. Karl [EMAIL PROTECTED] Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein
Re: Important OpenBSD errata
On 3/15/07, Ray Percival [EMAIL PROTECTED] wrote: You -do- know that this has been on the errata page since Friday, right? Because as worried as you are and as important as this is to you you take the responsibility to check said page every day, of course. Oh wait. No you don't. Or use the magical, asynchronous, server-push, web-4.0pre1-alpha technology called the source-changes mailing list -- GDB has a 'break' feature; why doesn't it have 'fix' too?
Re: Important OpenBSD errata
You have a valid point: any bug is a security problem. However, the topic is not my management practices and the tradeoffs involved therein. The topic is the efficacy of the security-announce list. If I knew security-announce was broken I could write a screen-scraper to check the errata page for me. The simple assumption that has never failed me is everything is broken, don't trust it. Cheers, A
Re: Important OpenBSD errata
On Mar 16, 2007, at 12:36 AM, Karl O. Pinc wrote: You have a valid point: any bug is a security problem. However, the topic is not my management practices and the tradeoffs involved therein. The topic is the efficacy of the security-announce list. If I knew security-announce was broken I could write a screen-scraper to check the errata page for me. feed://flirble.disruptiveproactivity.com/rss/openbsd_stable_src.rss feed://flirble.disruptiveproactivity.com/rss/openbsd_stable_ports.rss feed://ports.openbsd.nu/rss/all -- bda
Re: Important OpenBSD errata
On 3/15/07, Karl O. Pinc [EMAIL PROTECTED] wrote: On 03/15/2007 10:48:49 PM, Ray Percival wrote: On Mar 15, 2007, at 7:31 PM, Karl O. Pinc wrote: I rely on having a clear channel for security related problems. The only communication problem here is that you don't look at the information that the project puts out there for you. The project says it will announce security errata on the security-announce list. I _am_ assuming this will be done in a timely fashion... This does not seem like an unreasonable assumption. I bet you'd also like somebody other than you to patch your systems in a timely fashion. If security-announce is not a place for timely security announcments then change the description, or get rid of it. Which brings the discussion back to where it started, and where it belongs. Security isn't about receiving notifications to your Inbox in a timely fashion. It is about being proactive yourself. You should be the one taking measures to secure your systems, and you should be the one ACTIVELY LOOKING for problems. Watching mailing lists isn't enough, and this was announced very early on the ERRATA page. Do something for yourself. -- Kian Mohageri
Re: Important OpenBSD errata
On 03/15/2007 11:29:22 PM, Theo de Raadt wrote: I looked for your name on the donations list. I don't see it. I only buy CDs and stuff occasionally, and generally invest time in what I hope are productive ways. How much do I need to donate to keep from having to waste my time in unproductive threads like this? Seriously. Karl [EMAIL PROTECTED] Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein
Re: Important OpenBSD errata
I looked for your name on the donations list. I don't see it. I only buy CDs and stuff occasionally, and generally invest time in what I hope are productive ways. I think you bought one CD. Now you spout and whine. Is that a Robert Heinlein philosophy? How much do I need to donate to keep from having to waste my time in unproductive threads like this? Is that a Robert Heinlein philosophy too? +1.7733632105
Re: Important OpenBSD errata
On Mar 16, 2007, at 1:09 AM, Theo de Raadt wrote: I looked for your name on the donations list. I don't see it. I only buy CDs and stuff occasionally, and generally invest time in what I hope are productive ways. I think you bought one CD. Now you spout and whine. Is that a Robert Heinlein philosophy? How much do I need to donate to keep from having to waste my time in unproductive threads like this? Is that a Robert Heinlein philosophy too? I HAVE donated both hardware and cash over the last few years, as well as buying CDs and shirts; does that mean I get to have an opinion? 1) It is reasonable to assume that if a security-announce@ list exists, it will be utilized consistently. If it is not, the documentation should be updated to reflect that. 2) There are numerous other ways to track changes to -STABLE. Using one of them is also reasonable; if they were referenced somewhere in the documentation that would certainly be helpful (but would generate management overhead). Heinlein also wrote TANSTAAFL. -- bda
Re: Important OpenBSD errata
Karl O. Pinc wrote: On 03/15/2007 11:29:22 PM, Theo de Raadt wrote: I looked for your name on the donations list. I don't see it. I only buy CDs and stuff occasionally, and generally invest time in what I hope are productive ways. And what are the developers doing with their time? They give it to you and you have the got to complain on top of it! So, they should waist their time to make you happy because you are to lazy to check for yourself! How much do I need to donate to keep from having to waste my time in unproductive threads like this? If you even have to ask this question, I fell sorry for you! Seriously. Seriously! Daniel
Re: Important OpenBSD errata
On 03/16/2007 12:09:46 AM, Theo de Raadt wrote: I looked for your name on the donations list. I don't see it. I only buy CDs and stuff occasionally, and generally invest time in what I hope are productive ways. I think you bought one CD. I think I've bought 4 over the last 5 years. I wouldn't swear to it. I spent at least one release learning to do it myself sans cd. And 1 t-shirt for sure. Believe me or not. At least one cd was bought under a different name and I don't have the receipt any more. Now you spout and whine. Is that a Robert Heinlein philosophy? I pointed out what I thought was a problem, and I tried to be respectful when I did so. One security errata did not get announced on the security-announce mailing list. Nobody wants to acknowledge it as a problem. Fine. Is it a big problem? Not really. But people seem to want to give me shit for mentioning it. That's fine too but I've a weakness for standing up to agression. I apologize if the repetition to which that has led has made this into a bigger deal than it is. How much do I need to donate to keep from having to waste my time in unproductive threads like this? Is that a Robert Heinlein philosophy too? I thought you were offering. Karl [EMAIL PROTECTED] Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein
Re: Important OpenBSD errata
Karl O. Pinc wrote: On 03/15/2007 11:29:22 PM, Theo de Raadt wrote: I looked for your name on the donations list. I don't see it. I only buy CDs and stuff occasionally, and generally invest time in what I hope are productive ways. like bitching about stuff that you, as a security professional, should already know? how notably productive! if you can't look smart because you weren't looking the right spot for this information, then perhaps your customers really should reconsider how smart they thought you were. offhand i remember having had a favorable impression of your skills from your previous posts and this hissy fit doesn't make you look any smarter. if i hired you as a consultant, looked you up on google and saw this little thread, i'd really think twice about listening to you next time. unless you're posting under a pseudonym you may have turned stubbing your toe into a full blown shot yourself in the foot. How much do I need to donate to keep from having to waste my time in unproductive threads like this? how much do i need to donate to stop other whiners from starting threads like this? if you're a security consultant in a 1st world country whose job depends on openbsd and you haven't donated any significant amount, you're one greedy SOB. Seriously. Karl [EMAIL PROTECTED] Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein
Re: Important OpenBSD errata
On 03/15/2007 11:55:44 PM, Kian Mohageri wrote: Security isn't about receiving notifications to your Inbox in a timely fashion. It is about being proactive yourself. You should be the one taking measures to secure your systems, and you should be the one ACTIVELY LOOKING for problems. Watching mailing lists isn't enough, and this was announced very early on the ERRATA page. Perhaps my problem is that until this thread it wasn't clear to me that the errata page was inherently more reliable than the mailing list. From a technical perspective I see no reason why either can't be equally reliable. How am I to know? Karl [EMAIL PROTECTED] Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein
Re: Important OpenBSD errata
* Karl O. Pinc [EMAIL PROTECTED] [2007-03-16 04:23:00]: No, but if security errata announcements arn't delivered in a fashion that delivers them to a human then they do no good. I should not be expected to peruse the misc@openbsd.org list to find errata announcements. OpenBSD says announcements will be made on security-announce when patches become available. This did not happen. Ergo, something is broken. I can't fix it. It may not be fixable, but if it is fixable then it should be fixed. We should not all just pretend it didn't happen. If there is something that can be fixed I'd like to hear about it when it gets fixed. Hence my post. Now, I've harrassed this forum with my obsessive-compulsive rants before, so I can guarantee you you're going to get nothing. OpenBSD actually does not owe you anything. If you really want to stay ontop of OpenBSD going-ons, I suggest you subscribe to [EMAIL PROTECTED] Public things hit that first. Yes, it does seem a bit silly that security-announce@ is a bit flakey sometimes and this has been ranted about before. Nothing has changed it's usage. But this problem showed up on errata.html, misc@, undeadly.org, osnews.com, some other blogs, news sites, and finally slashdot. You're bound to read one of those (however I wouldn't count on slashdot since it's just inflamatory bullshit read by a bunch of microsofters who wish they could even install linucks; whether this is due to their stupidity or the poor quality of linux is anyone's guess). I digress. If you _really_ want to stay ontop of things, you have to take action yourself beyond the cron job that gets your mail. Sorry, that's just the way it is, so I suggest you adapt to it. -- Travers Buda
Re:
Hi x x, I have it installed, the sets and that, but no ports or anything. Okay, that's clear then. You DON'T install snapshot packages on your brand new 4.0 installation. IMHO, you need to be comfy with 4.0 release and 4.0 packages before attempting to do anything which involves -current or snapshots. Go read the FAQ again. ;-) You'll have to learn to walk before you can run. Also, there is a nice and friendly newbies list, which you might like to join. HTH and have fun... Nico
Re: Important OpenBSD errata
On 03/16/2007 12:40:57 AM, Daniel Ouellet wrote: And what are the developers doing with their time? They give it to you and you have the got to complain on top of it! So next time I shouldn't post when I see a problem? That'll help, not. Karl [EMAIL PROTECTED] Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein
Re: Important OpenBSD errata
I apologise to the list for responding to the flames. I made my point and went beyond into unproductiveness. I'm sorry and I'll stop now. Karl [EMAIL PROTECTED] Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein
Re: Important OpenBSD errata
http://www.openbsd.org/mail.html --- *security-announce* Security announcements. This low volume list receives OpenBSD security advisories and pointers to security patches as they become available.---Martin and Karl have valid points in their initial emails. /Tony S -- Tony Sarendal - [EMAIL PROTECTED] IP/Unix -= The scorpion replied, I couldn't help it, it's my nature =-
Re: Important OpenBSD errata
On Fri, 16 Mar 2007 06:03:49 + tony sarendal [EMAIL PROTECTED] wrote: http://www.openbsd.org/mail.html --- *security-announce* Security announcements. This low volume list receives OpenBSD security advisories and pointers to security patches as they become available.---Martin and Karl have valid points in their initial emails. Only it doesn't actually say how timely it is supposed to be or even that all advisories and patches will have a corresponding email. Sure, you could say it's implied but it's sure not spelled out and the OpenBSD project isn't exactly overflowing with personell. But maybe Karl and Martin are volunteering to maintain security-announce. -- Lars Hansson [EMAIL PROTECTED]
Re: Important OpenBSD errata
* tony sarendal [EMAIL PROTECTED] [2007-03-16 06:03:49]: http://www.openbsd.org/mail.html --- *security-announce* Security announcements. This low volume list receives OpenBSD security advisories and pointers to security patches as they become available.---Martin and Karl have valid points in their initial emails. /Tony S It's important to put yourself in Theo et al.'s shoes. Here's a group of people who write code for free, and then give it away for free. There's no serious cash inflow to enable them to do everything they want. The code can be used by anybody for whatever purpose, like: making money! And does that money ever find it's way back to OpenBSD? I'm talking about big corporations here. OpenSSH is in _everything_. It's only natural that OpenBSD should feel a sense of ingratitude... because there is ingratitude. To add insult to injury, people ask for more than what is freely offered. Example: this thread. If you want to see X feature, hire one of the developers. If you want to keep getting releases, pay Theo's hydroponics.. err electric bill. etc etc -- Travers Buda
