openbsd tar multi volume
Hi, finally filled up my bsd system over 20Gb and need to use multiple tapes. Isn't so easy manually spliting the backup between several tapes so I want to span the archive over multiple tapes. On other unix systems tar would just ask for the next tape but on my openbsd 4.2 box it seems to exit the tar session with and end of media error. I'm taring to /dev/rst0 Any idea's? -khalid
Re: Halt -p on amd64
Hi! On Thu, Feb 14, 2008 at 10:35:45AM +0100, Jordi Espasa Clofent wrote: 'halt -p' doesn't work fine in amd64; if you execute this command, the box remains waiting you press a key to make a reboot. And the last goal is obviously to make a complete power off. It doesn't work on a few systems. It seems to be an issue with some ACPI implementations. For example, I have the same problem on my T61 running amd64 GENERIC.MP... which is really annoying on a laptop without working suspend. I once even forgot to push the power button after shutting it down and it keept running in my laptop bag until the battery ran out... reyk
Re: Multi-Threaded SSH/SCP made by university of Puttsburgh
I can take this only so long before replying... POSIX threads are a complete a total disaster. They are essentially non portable. Anyone who has written threaded code that has to be portable has at one point considered suicide. We are not talking about running on OpenBSD and Linux here; we are talking about running on virtually ALL operating systems. If you honestly believe you can make that work reliably and securely you have never written any portable code of any significant size. The discussion on kernel threads is irrelevant. It is not about having some lower level support that will magically make threads not suck. The threading model is inherently flawed. Again writing a program of any size will teach you this lesson the hard way; especially if you have the honor of being part of a team of 500 people. Nothing is more fun than having short lived threads silently corrupting the heap in 100% non reproducible ways. Let the finger pointing begin... But don't believe me, try it for yourself. Write a program that listens on sockets in a thread and have them signal an external entity when they wake up. Have the external entity acknowledge the signal by returning a different signal. Oh and make that work on Linux 2.0, 2.2, 2.4 2.6. When you get that right go port it the BSDs. Oh and the advanced hacker does this without #ifdef. Have fun. All this aside do you honestly think that ssh is slow and needs a boost? I don't know about you but decrypting one character as soon as I type it works well enough for me. Benchmarking often is stupid and yields results that are wildly misinterpreted. The performance numbers sure show that it is faster and therefore better right? Quite the opposite. We are talking about one of the most attacked pieces of software in the history of the internet people. Faster != better AT ALL. On Wed, Feb 13, 2008 at 11:46:25PM -0600, Matthew Weigel wrote: Geoff Steckel wrote: This discussion of threads is isomorphic to: Why do CPUs have MMUs? Why don't we write good guys' timeshared programs which run cooperatively and noninterfering in a shared unprotected environment? Answer: it's too hard to write perfect programs. Compartmentalized security simplifies each component and drastically simplifies keeping the whole system running well. Yes, it is. It's controlled by the code you write. That makes it implicit and/or accidental. Data sharing between any parties must be explicit and declared, otherwise it is either a bug now or a bug later when the next maintainer doesn't know. Accidental state sharing is by definition a fatal bug. How is it qualitatively more implicit than IPC? they encode state implicitly in the program counters of the threads The hell? OK, you're debugging a multithreaded program. Quick, what's the state of all the threads now? Not encoded in data? Hmm how long is it going to take to discover it. Have you ever had to debug a multi-threaded application? You can use a debugger to check the state just the same. they are extremely difficult to guard against external conditions such as unexpected incoming data Incoming from where? Any useful program does I/O. Otherwise the computer is a space heater. So, other than pattern generators with built in data, every useful program must take input. Any multithreaded program which I've observed has some form of asynchronous inputs. Now, what happens when an unexpected datum arrives. So it's expected in the sense that there is a thread looking for input on this file descriptor. But it's unexpected in the sense of... how? complete and correct error recovery requires complex and error prone code Welcome to non-trivial software development. That's exactly the point. Subtle but extremely important. Every effort must be made to keep the software as simple as possible so that it is comprehensible. Incomprehensible software is by definition a fatal bug. The point is that all non-trivial software development has the problem that complete and correct error recovery requires complex and error-prone code? Any construct which causes complexity disproportionate with the total system gain (development maintenance resources, run time resources, etc. vs useful output) must be avoided. Finally, something we agree on. Make the code as simple as you can - but no simpler (to paraphrase Einstein). Look, all of these issues - *all* of them - are exactly the sorts of problems that the developers need to get a handle on in order to support the SMP kernel, never mind kernel threads. If they can't get it right, then they might as well say so, and we can all go back to uniprocessor machines for anything secure, and run Linux or FreeBSD for anything performance-sensitive. Now, I haven't looked at the exact code written, but based on the descriptions I'm guessing it's a worker thread model
Re: rdr question
Hi, Monah Baki schrieb: rdr pass on $ext_if proto tcp to port 8080 - 192.168.3.105 port 8080 rdr pass on x.x.x.x proto tcp to port 8080 - 192.168.3.106 port 8080 From outside my network if I enter in my browser proxy setting x.x.x.x 8080 which is the alias, I get redirected to the proxy 192.168.3.105 not the 106. If I comment rdr pass on $ext_if proto tcp to port 8080 - 192.168.3.105 port 8080 then it works fine, my rdr rule works. Since x.x.x.x also belongs to $ext_if only the first RDR rule is taken... maybe change it like this: rdr pass on $ext_if proto tcp to ($ext_if:0) port 8080 \ - 192.168.3.105 port 8080 rdr pass on $ext_if proto tcp to x.x.x.x port 8080 \ - 192.168.3.106 port 8080 ($ext_if:0) is the main IP of the interface Michael
vpn altq voip question
Hi, I have a three site vpn on 4.2 with a voip enabled PBX on each lan, linked with SDSL lines. This works as expected. However, I need to prioritize the PBX to PBX traffic, they have fixed lan IPs, and am looking for pointers on the best way to accomplish this. After reading the docs, I am not quite clear on how to classify and queue the vpn traffic, so if anyone has advice or links to docs or sample pf.confs, it would be much appreciated, as testing on a live system is a bit hazardous. cheers, mike
Re: IBM ServeRaid 5i - installer unable to find disks
Fredrik Hansson schreef: Matt wrote: Can anyone shine some light on how to actually make this controller work with OpenBSD? Or am I overlooking something obvious? ips is not included in the ramdisk kernels. I had the same problem and my solution was to copy the two lines for ips from /usr/src/sys/arch/i386/conf/GENERIC to /usr/src/sys/arch/i386/conf/RAMDISC_CD and then build a release. -- Fredrik Thanks, that worked. I had never build a release before so I did it as described in the FAQ [1] on a different non-important machine, including a complete build of the userland binaries. Then I build a release from that. Eventually I did end up with the ips(4) enabled cd42.iso in the /usr/rel directory. Reading release(8) I could not find if there was a shortcut in doing this? Could one just build parts of the system needed for cd42.iso ? Thanks again, Matt [1] http://www.openbsd.org/faq/faq5.html
Re: Multi-Threaded SSH/SCP made by university of Puttsburgh
On Wed, Feb 13, 2008 at 5:23 PM, Matthew Weigel [EMAIL PROTECTED] wrote: bofh wrote: 2) lack of tuits to take on a major change for not really any major perceived gains: this is not an itch any of the developers currently have. ...except the developers (outside OpenBSD) who developed the patch. and they have a patch and are free to use it, as is anyone else who thinks ssh is too slow. i think it's great that pitt made a patch, but i don't expect to see this in tree. and that doesn't bother me. why does it bother you?
ppp set speed problem?
Hello misc@, can you please answer a question? How can I solve the speed problems with ppp,pppd, like: itp[p3]:~sudo ppp Working in interactive mode Using interface: tun0 ppp ON itp set speed 921600 Warning: 921600: Invalid speed Warning: usage: set speed value|sync ; you can only set speed 230400 in OpenBSD. For 3G devices, for exmp. it is too small speed... ? Thanks, -- Sergey Prysiazhnyi
Re: IBM ServeRaid 5i - installer unable to find disks
Jonathan Gray schreef: grange@ the author of the driver says there is still a data corruption bug in ips, so rather than enabling it on ramdisks I'll disable it in GENERIC tonight. Am I understanding correctly grange's info made you decide the ips driver should not be used _at all_ ? I was planning to put this box in production today but the 'data corruption' part got me worried. Is there more info available on what the author said? And is there anything we can / should do to accomodate a fix? Thanks.
