Re: Shellscript escaping problem
On Fri, Aug 03, 2012 at 10:41:09PM -0700, Philip Guenther wrote: On Fri, Aug 3, 2012 at 9:35 PM, David Diggles da...@elven.com.au wrote: ... here's an example of how not to script rsync, when just starting to learn how to script it got over complicated over time. i should rewrite it sometime :) ... I guess I don't understand the point of sending that out. It's like a generic ghost story: ...and the code walks the corridors of the office building to this day! There it is! Ah! If the goal is to help the inexperienced shell script writer avoid that fate, you must provide instruction and suggestions, not just set up your prior works up as warning. The beginner will be dazzled by the mess-o'-punctuation, but that doesn't help them see what they should do instead when they, in turn, find their own scripts crawling into the morass. Philip Guenther There were already excellent examples of what to do provided by others. What is wrong with an example of how bad spaghetti scripting looks like? I think there can be value in seeing an exagerrated example of what not to do. Furthermore, I provided my own script, not someone elses, because I am happy to own my own mistakes. Another good thing to teach. IMO, a teaching method that only ever teaches what to do, and never what not to do, and only ever provides instructions and guidance, risks creating the kind of box that breeds idiots with no ability to think for themselves.
Re: Shellscript escaping problem
On Sat, Aug 4, 2012 at 11:00 PM, David Diggles da...@elven.com.au wrote: What is wrong with an example of how bad spaghetti scripting looks like? I think there can be value in seeing an exagerrated example of what not to do. I don't think it's obvious to everyone that that was bad code. Indeed, there was that person in the past that wrote that code and decided it was the best they could do at that moment. What's to say some other person won't look at your code and say huh, looks better than some of my other scripts; I don't get what the problem is. Furthermore, I provided my own script, not someone elses, because I am happy to own my own mistakes. Another good thing to teach. True. IMO, a teaching method that only ever teaches what to do, and never what not to do, and only ever provides instructions and guidance, risks creating the kind of box that breeds idiots with no ability to think for themselves. In my experience as a student and teacher, the discussions of about what made something (a program, a work of art, a mathematical proof, a piece of music) better or worse were the most valuable part of reviewing the existing works. If just seeing the bad stuff without thinking about and recognizing what made it bad was enough to let you create good stuff, then Sturgeon's law would be false. Philip Guenther
Joyeria de Acero Inoxidable, Chapa de Oro y Relojes
MEDIO MAYOREO Y MAYOREO EN JOYERÍA DE ACERO INOXIDABLE, CHAPA DE ORO Y RELOJES Saludos, en nuestra empresa nos dedicamos a la importación y distribución de joyería en acero inoxidable calidad quirúrgica, chapa de oro de 18kt y relojes. En la actualidad somos la empresa con mayor surtido y mejor precio en toda la República Mexicana, tenemos modelos nuevos cada semana además de pertenecer a la Cámara de Joyería de Jalisco y participar en Expo Joya Cd. de México y Guadalajara. Contamos con tiendas físicas en la ciudad de Guadalajara, México DF y Mérida Yucatán. Con gusto nos complacería mostrarle nuestros productos para brindarle una referencia clara y precisa de la calidad de nuestras piezas y servicio. EL ACERO INOXIDABLE, LA JOYERÍA EN CHAPA DE ORO Y LOS RELOJES SON LA MEJOR SOLUCIÓN A LOS PROBLEMAS DE LA ESCASA VENTA DE JOYERIA DE ORO Y PLATA, SON PRODUCTOS INNOVADORES Y ECONOMICOS QUE SE VENDEN POR SI SOLOS, SE PUEDEN VENDER EN JOYERÍAS, TIENDAS DE REGALO, ESTÉTICAS, TIENDAS DE ROPA, ETC. O TAMBIEN PUEDEN VENDERLA ENTRE SUS CONOCIDOS Y AMIGOS AYUDANDO A LA ECONOMÍA FAMILIAR, YA QUE USTED RECIBIRÁ GANANCIAS POR LO MENOS DEL DOBLE DE LO INVERTIDO. www.importacionescori.com /P www.chapadeoro.com www.relojescori.com Ecuéntranos en facebook: www.facebook.com/icori
Scaricare il file allegato e compilare il modulo
Gentile Cliente, Stiamo aggiornando il nostro database utenti. Si prega di scaricare il file allegato e compilare il modulo Dopo aver inserito i dettagli clicca accedi. NOTA: Se non compilare il modulo in 48 ore portera alla cancellazione dell'account. POSTE ITALIANE 2012 [demime 1.01d removed an attachment of type APPLICATION/DEFANGED which had a name of verif.13484DEFANGED-htm]
Re: Kernel Level Audio Next Generation
On Tue, Jul 31, 2012 at 10:46:57PM +0300, Alexey Suslikov wrote: Hello misc. http://klang.eudyptula.org/ very interesting ideas. Just curious, why they didn't even try to evaluate OpenBSD sndio. An overall approach to the problem is interesting thing too Q: Why a audio system in the kernel? A: Because it's the only reasonable thing to do. IMHO it's not important; both kernel-mode and user-mode approaches can work, neither seems better. Both have their advantages. kernel-mode is thought to be better with respect to underruns, but that's not 100% true. Trying to explain. Underruns occur whenever an element in the audio processing chain doesn't complete its work before the deadline imposed by the hardware. This chain includes the audio player, which necessarily runs in user mode. Thus we have to get right audio programs (user-mode) first to avoid underruns. If you're able to write audio programs that don't underrun, then you're also able to write an audio daemon that doesn't underrun. No need to put the audio system in the kernel in this case. If you're unable to write audio programs that don't underrun, audio will stutter, and putting the audio system in the kernel won't fix stuttering, so no need to put the audio system in the kernel either. AFAICS, the main advantage of a kernel-mode implementation is to avoid the overhead of extra context switches. In the current sndio implementation the overhead of context switches is negligible compared to audio processing. The choice of moving parts of the OpenBSD audio sub-system out of the kernel is mostly for practical reasons; having less code with kernel privileges seems sane as well; A kind of if a program doesn't need kernel privileges then put it in user mode principle. What people think? Maybe we should write an article for wikipedia to make sndio more visible to rest of the world? Sure -- Alexandre
Re: 10Gbit Intel 10GbE SFP+ (82599) performance
On 05/08/12 00:13, Mike Belopuhov wrote: to elaborate on this point a bit: please make sure you understand what you're testing! tcpbench and iperf both test how fast your tcp or udp server running in userland can receive and transmit information through the socket interface. this has nothing to do with router workloads for example. Yes, we would like to be faster but to get more speed large changes are needed since currently only one CPU is doing all the work in the kernel. -- :wq Claudio Well if the OpenBSD is in the middle of two other machines like B in A-B-C and you do iperf/tcpbench between A and C then it is a valid test for router workloads, isn't it? Giannis
Re: 10Gbit Intel 10GbE SFP+ (82599) performance
On Sun, Aug 05, 2012 at 01:50:26PM +0300, Kapeatanakis Giannis wrote: On 05/08/12 00:13, Mike Belopuhov wrote: to elaborate on this point a bit: please make sure you understand what you're testing! tcpbench and iperf both test how fast your tcp or udp server running in userland can receive and transmit information through the socket interface. this has nothing to do with router workloads for example. Yes, we would like to be faster but to get more speed large changes are needed since currently only one CPU is doing all the work in the kernel. -- :wq Claudio Well if the OpenBSD is in the middle of two other machines like B in A-B-C and you do iperf/tcpbench between A and C then it is a valid test for router workloads, isn't it? Depends. tcpbench and iperf do not emulate real traffic. In most cases they will run a very limited number of sessions/flows. In the end you need to know if your profiling run does measure the right things. At least the tcpbench workload (tcp session in one direction) produce a not so common network pattern. iperf has a similar issue but comes with more buttons. In short tcpbench and iperf can give you an indication how a router behaves in your A-B-C test. -- :wq Claudio
getty
I would like to change /etc/ttys to get, for instance: ttyC3 /usr/libexec/getty std.192600 vt220 on secure instead of : ttyC3 /usr/libexec/getty std.9600 vt220 on secure Do you think i could run into problems ? Thanks in advance.
Re: 10Gbit Intel 10GbE SFP+ (82599) performance
On 2012-08-05, Kapeatanakis Giannis bil...@edu.physics.uoc.gr wrote: On 05/08/12 00:13, Mike Belopuhov wrote: to elaborate on this point a bit: please make sure you understand what you're testing! tcpbench and iperf both test how fast your tcp or udp server running in userland can receive and transmit information through the socket interface. this has nothing to do with router workloads for example. Yes, we would like to be faster but to get more speed large changes are needed since currently only one CPU is doing all the work in the kernel. -- :wq Claudio Well if the OpenBSD is in the middle of two other machines like B in A-B-C and you do iperf/tcpbench between A and C then it is a valid test for router workloads, isn't it? Well it's a valid test if you're interested in seeing how it performs when routing a single or limited number of flows but it's not valid for standard internet traffic forwarding. normal internet traffic has lots of separate flows, lots of destinations and a mixture of packet sizes. And normal is, of course, different depending on the network. Neither iperf/tcpbench are good for emulating this. People pay tens of thousands of (insert favourite currency unit here) for test equipment for this.. Can't remember if it came up in this thread yet or not, but make sure that pool_debug is off if you're doing performance testing.
Suspect fragmented packets.
Hi. I've had a bridged modem and OpenBSD gateway setup for years on a particular Australian ISP. I've never re-assembled packets and worried over MTU or fragments. Everything just worked ... Recently one of the companies I work for changed ISP. I swapped the relevant details on the gateway, hostname.pppoe0 and whatnot, and it seems that a significant portion of the web is inaccessible, most websites are accessible but many are not. DNS resolution seems fine for all domains and of the sites that won't work some of them will display a title in a browser on an internal client and that's it. Some of them will send all the html but ultimately not display. Most simply time out ... I've tred re-assembling packets but it doesn't help. I suspect I'm being sent fragmented packets with don't fragment set. Does this sound right? If this is right, could I achieve anything by explicitly allowing ICMP (datagram too large messages) expecting that the upstream hosts will set path MTU accordingly or is this a wasted effort. Either way, should I start re-assembling packets and scrubbing incoming and ignoring the don't fragment bit with no-df ... match in all scrub (no-df) Best wishes.
Re: OpenBSD on GitHub
On 2012-08-04, Tony ableton...@gmail.com wrote: Personally I'd love to make a fork and contribute back a ton of pull requests, mostly on the documentation side though. No need for all this complication of exporting/syncing between the version control system used by OpenBSD and another one for work directories - just work on an anoncvs checkout directly. The only operation that you can't do easily against an anonymous CVS server is adding a new directory, and in the majority of cases this is only an issue for ports diffs. N.B. if sending diffs (inline not attached) you'll probably need to use something other than the gmail web interface to send diffs as it usually corrupts them so that they don't apply cleanly.
Re: Suspect fragmented packets.
On Sun, Aug 5, 2012 at 7:50 AM, David Walker davidianwal...@gmail.com wrote: I've had a bridged modem and OpenBSD gateway setup for years on a particular Australian ISP. I've never re-assembled packets and worried over MTU or fragments. Everything just worked ... Recently one of the companies I work for changed ISP. I swapped the relevant details on the gateway, hostname.pppoe0 and whatnot, and it seems that a significant portion of the web is inaccessible, most websites are accessible but many are not. DNS resolution seems fine for all domains and of the sites that won't work some of them will display a title in a browser on an internal client and that's it. Some of them will send all the html but ultimately not display. Most simply time out ... I've tred re-assembling packets but it doesn't help. I suspect I'm being sent fragmented packets with don't fragment set. Does this sound right? If this is right, could I achieve anything by explicitly allowing ICMP (datagram too large messages) expecting that the upstream hosts will set path MTU accordingly or is this a wasted effort. Either way, should I start re-assembling packets and scrubbing incoming and ignoring the don't fragment bit with no-df ... match in all scrub (no-df) When using pppoe(4), MSS can be a problem. I recommend you read the MTU/MSS ISSUES section of the man page and see if that resolves your issue.
Re: Suspect fragmented packets.
Daniel Melameth daniel () melameth ! com wrote: When using pppoe(4), MSS can be a problem. I recommend you read the MTU/MSS ISSUES section of the man page and see if that resolves your issue. I have read and tried. As far as I can see there's an issue with incoming packets. AFAIUI, MSS will limit the size of outgoing. I'd like to know the relationship between that and path MTU and what I see as the apparent default block on ICMP in pf ... Sending packets is one thing but if a distant host is unable to determine the MTU for the next hop (to me) via ICMP then there's a problem right? Does setting MSS on PPP and therefore MTU affect this? Do I need to explicitly allow ICMP to enable this behaviour? Regardless, we're able to talk to the web in general and get good responses from almost everyone. I suspect some are sending ill-formed packets back which is the reason why pf has the no-df option. I haven't had to deal with it previously, my earlier ISP apparently scrubbed and waxed my packets for me. With Internode, I explicitly overturned the default 'set reassemble' to no and avoided MSS (and MTU) considerations and didn't worry about fragments and bad df bits ... Everything worked ... but that's Internode. Best wishes.
Re: getty
From my experience with high speed rs232 on Cisco devices it doesn't work too well, and very dependent on distance and cable type. 19200 was always safe and fast enough for _my_ use. BTW, 192600 is not a standard speed. HTH, Dan #13685 (RS/Sec/SP) The CCIE troubleshooting blog: http://dans-net.com Bring order to your Private VLAN network: http://marathon-networks.com On Sun, Aug 5, 2012 at 2:14 PM, Friedrich Locke friedrich.lo...@gmail.com wrote: I would like to change /etc/ttys to get, for instance: ttyC3 /usr/libexec/getty std.192600 vt220 on secure instead of : ttyC3 /usr/libexec/getty std.9600 vt220 on secure Do you think i could run into problems ? Thanks in advance.
Re: OpenBSD on GitHub
On Sat, Aug 04, 2012 at 07:05:38PM +0200, Marc Espie wrote: Well, git just has a different set of bugs than cvs. ... I would deem cvs MORE painful than git on average, it's just that we're more accustomed to the pain... Yes, this is right. And also there would be a price to pay in lost productivity in switching to a new system. To those very familiar with CVS and not very familiar with Git (or hg, et al), the benefits of switching are nebulous and uncertain, while the cost is very real. Over time, OpenBSD has done things that were in the no, never, just go away category just a few years before. I would not be too surprised if OpenBSD switched to a DVCS in the future, when it's a well considered switch and not a headlong rush into the next new thing. To those of us who see the benefits of DVCS it's frsutrating to wait, but OpenBSD has avoided many pitfalls by being conservative. In the meantime, OpenBSD uses CVS, and it's workable.
Re: getty
I meant 19200 not 192600! I am not using serials, but the computer console on mymonitor. What you think ? On Sun, Aug 5, 2012 at 1:43 PM, Dan Shechter dans...@gmail.com wrote: From my experience with high speed rs232 on Cisco devices it doesn't work too well, and very dependent on distance and cable type. 19200 was always safe and fast enough for _my_ use. BTW, 192600 is not a standard speed. HTH, Dan #13685 (RS/Sec/SP) The CCIE troubleshooting blog: http://dans-net.com Bring order to your Private VLAN network: http://marathon-networks.com On Sun, Aug 5, 2012 at 2:14 PM, Friedrich Locke friedrich.lo...@gmail.com wrote: I would like to change /etc/ttys to get, for instance: ttyC3 /usr/libexec/getty std.192600 vt220 on secure instead of : ttyC3 /usr/libexec/getty std.9600 vt220 on secure Do you think i could run into problems ? Thanks in advance.
Re: OpenBSD on GitHub
On Sun, Aug 05, 2012 at 10:46, Darrin Chandler wrote: On Sat, Aug 04, 2012 at 07:05:38PM +0200, Marc Espie wrote: Well, git just has a different set of bugs than cvs. ... I would deem cvs MORE painful than git on average, it's just that we're more accustomed to the pain... Yes, this is right. And also there would be a price to pay in lost productivity in switching to a new system. To those very familiar with CVS and not very familiar with Git (or hg, et al), the benefits of switching are nebulous and uncertain, while the cost is very real. I will add a somewhat controversial viewpoint to the mix. Because cvs makes working with branches and large diffs so painful, it forces developers to split their work into smaller pieces. In OpenBSD, that's a good thing. Keeping your changes in a private fork is difficult, which is good. It means fewer private forks. If every developer could maintain a branch with some private tweaks, and not bother integrating their changes or fixing regressions, progress would grind to a halt. [I have mentioned this to people before and their eyes just about popped out of their head. I don't expect everyone to agree.] github is all about social coding and they have a point. But many of the things they enable are considered antisocial in the OpenBSD development process.
Re: Suspect fragmented packets.
On Mon, Aug 06, 2012 at 12:54:48AM +0930, David Walker wrote: Daniel Melameth daniel () melameth ! com wrote: When using pppoe(4), MSS can be a problem. I recommend you read the MTU/MSS ISSUES section of the man page and see if that resolves your issue. I have read and tried. As far as I can see there's an issue with incoming packets. AFAIUI, MSS will limit the size of outgoing. I'd like to know the relationship between that and path MTU and what I see as the apparent default block on ICMP in pf ... Sending packets is one thing but if a distant host is unable to determine the MTU for the next hop (to me) via ICMP then there's a problem right? Does setting MSS on PPP and therefore MTU affect this? Do I need to explicitly allow ICMP to enable this behaviour? The MSS field from your syn packages tells the other side what max package size you accept. I found this white paper helpful to understand MTU, PMTUD and MSS: http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml Remi
Re: OpenBSD on GitHub
On Sun, Aug 05, 2012 at 03:00:04PM -0400, Ted Unangst wrote: I will add a somewhat controversial viewpoint to the mix. Because cvs makes working with branches and large diffs so painful, it forces developers to split their work into smaller pieces. In OpenBSD, that's a good thing. Keeping your changes in a private fork is difficult, which is good. It means fewer private forks. If every developer could maintain a branch with some private tweaks, and not bother integrating their changes or fixing regressions, progress would grind to a halt. [I have mentioned this to people before and their eyes just about popped out of their head. I don't expect everyone to agree.] I don't find this controversial, except the notion that sticking with blunt tools to solve a human/procedural problem is a good idea. It also doesn't work, even if it appears to work: how many devs have I heard talk about a local tree they've maintained for a long time with changes that haven't yet gone in? Quite a few. When the changes go in, they come in small chunks, but the long-lived forks exist. Small commits are largely preferred by pretty much all of the sensible people I know, and OpenBSD culture clearly prefers/demands them. I'd be surprised if giving people sharper tools would do much harm. github is all about social coding and they have a point. But many of the things they enable are considered antisocial in the OpenBSD development process. There can be public read-only git without github, and I'd think self-hosting would be a much better fit for OpenBSD.
Re: Kernel Level Audio Next Generation
On 08/05/2012 06:02 AM, Alexandre Ratchov wrote: On Tue, Jul 31, 2012 at 10:46:57PM +0300, Alexey Suslikov wrote: Hello misc. http://klang.eudyptula.org/ very interesting ideas. Just curious, why they didn't even try to evaluate OpenBSD sndio. An overall approach to the problem is interesting thing too Q: Why a audio system in the kernel? A: Because it's the only reasonable thing to do. IMHO it's not important; both kernel-mode and user-mode approaches can work, neither seems better. Both have their advantages. kernel-mode is thought to be better with respect to underruns, but that's not 100% true. Trying to explain. Underruns occur whenever an element in the audio processing chain doesn't complete its work before the deadline imposed by the hardware. This chain includes the audio player, which necessarily runs in user mode. Thus we have to get right audio programs (user-mode) first to avoid underruns. If you're able to write audio programs that don't underrun, then you're also able to write an audio daemon that doesn't underrun. No need to put the audio system in the kernel in this case. If you're unable to write audio programs that don't underrun, audio will stutter, and putting the audio system in the kernel won't fix stuttering, so no need to put the audio system in the kernel either. AFAICS, the main advantage of a kernel-mode implementation is to avoid the overhead of extra context switches. In the current sndio implementation the overhead of context switches is negligible compared to audio processing. The choice of moving parts of the OpenBSD audio sub-system out of the kernel is mostly for practical reasons; having less code with kernel privileges seems sane as well; A kind of if a program doesn't need kernel privileges then put it in user mode principle. What people think? Maybe we should write an article for wikipedia to make sndio more visible to rest of the world? Sure -- Alexandre Yes, no, maybe, your mileage may vary... There are two separate issues here: throughput/bandwidth and latency. Confusing these is a very common misconception. You can have all the bandwidth (CPU disk) in the world, but if program latency (buffer size / sample rate), you will have over/underruns. If (buffer size / sample rate) is too large, then it is possible that there will be large latencies when starting stopping, etc. To have a system which is agile and does not over/underrun, the hardware should be controlled by a pair of functionalities: 1) a kernel function or a process running at real-time guaranteed latency priority which directly controls the hardware. 2) a user process running at a lower priority but one higher than processes doing interruptible long-running tasks. Its latency must be controlled as well as possible. Functionality #1 must never use a blocking system call except a poll/select or something similar. It should use a hardware buffer sized for the best compromise between desired responsiveness and CPU usage tending the buffers. This process/kernel function should then talk to functionality #2 using buffers sized for the greater latency of the non-real-time process. Functionality #2 can control the hardware quickly via the real-time function yet it can buffer large quantities of data for efficient use of its resources and to compensate for large latency. This process must run at a priority sufficiently high to take precedence over updating the screen or other indefinitely CPU-intensive tasks. It does format conversion, resampling, and other tasks which consume relatively large amounts of CPU or memory. It is often helpful to store audio on a dedicated disk to reduce or eliminate queueing delays. I've implemented such an architecture on a 1 MIPS machine handling 16 in and 16 out channels simultaneously. The bottleneck was the disk drive. Applications of this type almost always work best when engineered throughout with reducing latency as the top priority. Current CPUs and disks are capable of handling a huge number of audio channels if properly used. I.e. get the video out of the way, ensure low interrupt latency by eliminating all kernel spins or indefinitely long loops with interrupts blocked, etc. Geoff Steckel
Re: OpenBSD on GitHub
I don't find this controversial, except the notion that sticking with blunt tools to solve a human/procedural problem is a good idea. How else should I, as the maintainer of the trunk, contain the damage from these human/procedural problems? Careful -- every suggestion you want to suggest now makes the job of the trunk maintainer harder. Every single one of them. If people don't depend on the trunk as their primary, the trunk rots. If people have easy branch tools, they use the branches. It also doesn't work, even if it appears to work: how many devs have I heard talk about a local tree they've maintained for a long time with changes that haven't yet gone in? Quite a few. Those are not public branches. They are used by one (maybe two) developers to advance something big. But not everything is big. Lots of important things are very small, and don't need a branch. Yet the answer heard over and over again is: branches are good, they should be used for almost everything. Except once again, that infects those people's trees, and they don't test the trunk, and once instabilities are introduced by another developer they abandon the head of the trunk and run something else and we don't get those bugs fixed until the release process. I see other projects falling into this problem all the time. It is awesome. When the changes go in, they come in small chunks, but the long-lived forks exist. No, these long-lived forks are deleted when their changes go into the trunk. They are just a local development process tool; some people manage to do them without rcs type models, yet others like their own rcs's. Here in OpenBSD, there are no such long lived forks. Maybe somewhere else. But look at the list you are on... Small commits are largely preferred by pretty much all of the sensible people I know, and OpenBSD culture clearly prefers/demands them. I'd be surprised if giving people sharper tools would do much harm. Ha ha. I watch other projects. You see what looks like small commits, except the care of moving things from their own branch to the trunk is often highly sloppy -- by nature people are careless and will not re-test their trunk commits independently. So they break the head of the trunk. This pisses off developers who rely on the trunk. Eventually they learn to rely on their own safer branches and only update once in a while when the trunk is safe. Do you see where this is going? Incredible division of labour when it comes to testing. And who eventually gets burned the most by this? The release engineer... if a release is ever done. github is all about social coding and they have a point. But many of the things they enable are considered antisocial in the OpenBSD development process. There can be public read-only git without github, and I'd think self-hosting would be a much better fit for OpenBSD. If people only used such trees for reading, fine. But they will run them, and then not test the trunk. Every 6 months we ship the trunk. How does it become solid if everyone runs something else?
Re: getty
you must read really fast! I prefer to set mine to 300 so I don't need to pipe things to more :) Seriously though, what are you trying to achieve with this setting? just because the text will scroll faster doesn't mean the machine will run faster... it might even slow things down (i have no evidence for this, other than that Theo company tend to pick sane defaults) Ben On Aug 5, 2012, at 10:50 AM, Friedrich Locke friedrich.lo...@gmail.com wrote: I meant 19200 not 192600! I am not using serials, but the computer console on mymonitor. What you think ? On Sun, Aug 5, 2012 at 1:43 PM, Dan Shechter dans...@gmail.com wrote: From my experience with high speed rs232 on Cisco devices it doesn't work too well, and very dependent on distance and cable type. 19200 was always safe and fast enough for _my_ use. BTW, 192600 is not a standard speed. HTH, Dan #13685 (RS/Sec/SP) The CCIE troubleshooting blog: http://dans-net.com Bring order to your Private VLAN network: http://marathon-networks.com On Sun, Aug 5, 2012 at 2:14 PM, Friedrich Locke friedrich.lo...@gmail.com wrote: I would like to change /etc/ttys to get, for instance: ttyC3 /usr/libexec/getty std.192600 vt220 on secure instead of : ttyC3 /usr/libexec/getty std.9600 vt220 on secure Do you think i could run into problems ? Thanks in advance.
ypldap
Hi folks, will ypldap serve normall files (but group and passwd) just like ypserv ? I mean: amd.home, ethers, etc . Thanks in advance.
Re: OpenBSD on GitHub
On Sun, Aug 05, 2012 at 03:00:04PM -0400, Ted Unangst wrote: On Sun, Aug 05, 2012 at 10:46, Darrin Chandler wrote: On Sat, Aug 04, 2012 at 07:05:38PM +0200, Marc Espie wrote: Well, git just has a different set of bugs than cvs. ... I would deem cvs MORE painful than git on average, it's just that we're more accustomed to the pain... Yes, this is right. And also there would be a price to pay in lost productivity in switching to a new system. To those very familiar with CVS and not very familiar with Git (or hg, et al), the benefits of switching are nebulous and uncertain, while the cost is very real. I will add a somewhat controversial viewpoint to the mix. Because cvs makes working with branches and large diffs so painful, it forces developers to split their work into smaller pieces. In OpenBSD, that's a good thing. Keeping your changes in a private fork is difficult, which is good. It means fewer private forks. If every developer could maintain a branch with some private tweaks, and not bother integrating their changes or fixing regressions, progress would grind to a halt. [I have mentioned this to people before and their eyes just about popped out of their head. I don't expect everyone to agree.] ++1 here. My only experience with a project that moved from cvs to git was that a) the number of brances exploded and b) the number of repositories containing branches exploded and were erratically interconnected. This resulted in many rotting branches, many private playgrounds and far less incentive to move forward together. I particularly enjoyed messages containing lists of random hex numbers that one should revert, merge with or sacrifice chickens over if one could only find the appropriate repository. OK, one experience but it left an indelible impression. :-) I think git gives you a lot of rope. Which people use to hang themselves (and others!) as often as they use it to build a safety net. ... Ken github is all about social coding and they have a point. But many of the things they enable are considered antisocial in the OpenBSD development process.
Re: OpenBSD on GitHub
On Sun, Aug 05, 2012 at 02:14:56PM -0600, Theo de Raadt wrote: I don't find this controversial, except the notion that sticking with blunt tools to solve a human/procedural problem is a good idea. How else should I, as the maintainer of the trunk, contain the damage from these human/procedural problems? Careful -- every suggestion you want to suggest now makes the job of the trunk maintainer harder. Every single one of them. If people don't depend on the trunk as their primary, the trunk rots. If people have easy branch tools, they use the branches. It also doesn't work, even if it appears to work: how many devs have I heard talk about a local tree they've maintained for a long time with changes that haven't yet gone in? Quite a few. Those are not public branches. They are used by one (maybe two) developers to advance something big. I agree. If I implied that public branches were good then I should have been more clear. The -current is (almost) always best and release like clockwork attitudes have paid large dividends, and that goes hand in hand with trunk working as you say. The private branches (or whole separate trees!) seem like another matter to me. In git, working with branches and keeping them in sync is fairly easy, as is sharing directly (not through the central repo) with others. But not everything is big. Lots of important things are very small, and don't need a branch. Yet the answer heard over and over again is: branches are good, they should be used for almost everything. Except once again, that infects those people's trees, and they don't test the trunk, and once instabilities are introduced by another developer they abandon the head of the trunk and run something else and we don't get those bugs fixed until the release process. I see other projects falling into this problem all the time. It is awesome. Back when CVS was in widespread use, people still did stupid things. They do stupid things now with git. I'm one of those people who like to make branches for everything, but I still test against trunk. Of course I do. That's what will get committed to the central repo, so that's what matters. When the changes go in, they come in small chunks, but the long-lived forks exist. No, these long-lived forks are deleted when their changes go into the trunk. They are just a local development process tool; some people manage to do them without rcs type models, yet others like their own rcs's. Here in OpenBSD, there are no such long lived forks. Maybe somewhere else. But look at the list you are on... This time I was definitely unclear. Yes, delete after merging with trunk. Small commits are largely preferred by pretty much all of the sensible people I know, and OpenBSD culture clearly prefers/demands them. I'd be surprised if giving people sharper tools would do much harm. Ha ha. I watch other projects. You see what looks like small commits, except the care of moving things from their own branch to the trunk is often highly sloppy -- by nature people are careless and will not re-test their trunk commits independently. So they break the head of the trunk. This pisses off developers who rely on the trunk. Eventually they learn to rely on their own safer branches and only update once in a while when the trunk is safe. Do you see where this is going? Incredible division of labour when it comes to testing. And who eventually gets burned the most by this? The release engineer... if a release is ever done. I won't vouch for what unsensible people do. Of the various ways I've seen people do things, trunk is reliable works the best by a long shot in my experience. You can do the trunk is gee whiz cutting edge with CVS, too. We've both seen projects do that with CVS. It stinks. But that's not a CVS vs. Git thing. github is all about social coding and they have a point. But many of the things they enable are considered antisocial in the OpenBSD development process. There can be public read-only git without github, and I'd think self-hosting would be a much better fit for OpenBSD. If people only used such trees for reading, fine. But they will run them, and then not test the trunk. Every 6 months we ship the trunk. How does it become solid if everyone runs something else? I'm not sure this would be the case to any larger degree than now, but I don't understand your reasoning there so it's likely I'm missing something. I think Git can support the workflow you want, but that doesn't matter. I do not expect or want to change your mind, and do not expect to see an official OpenBSD git repo soon, if ever. It should only ever happen if it makes sense to you and the other OpenBSD devs, to further the underlying goals of the project. Until then, it would be stupid to switch. So at this point I don't even *want* you to switch. Not yet, anyway.
tmux, multiple prefix keys
Hi! I'm trying to digest tmux's man page's statement, that it is possible to configure more than one prefix key, and each one will work individually. Now when I execute 'set-option -g prefix ^b,^a', I get Bad key: ^b,^a, what is somehow understandable. But I can't seem to figure out a variation of escaping/quoting and/or separating the prefix keys to make tmux accept them. Is this some future feature which accidentally made it to the man page? Thanks, Daniel -- LÉVAI Dániel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
Re: Suspect fragmented packets.
On Sun, Aug 5, 2012 at 9:24 AM, David Walker davidianwal...@gmail.com wrote: Daniel Melameth daniel () melameth ! com wrote: When using pppoe(4), MSS can be a problem. I recommend you read the MTU/MSS ISSUES section of the man page and see if that resolves your issue. I have read and tried. What have you tried? As far as I can see there's an issue with incoming packets. AFAIUI, MSS will limit the size of outgoing. TCP negotiates MSS so a TCP session will never have an MSS higher than what one side can accept. I'd like to know the relationship between that and path MTU and what I see as the apparent default block on ICMP in pf ... Sending packets is one thing but if a distant host is unable to determine the MTU for the next hop (to me) via ICMP then there's a problem right? There is no default block of ICMP. As a matter of fact, unlike some other poor firewall implementations that break PMTU (and this might be what you are experiencing with some hosts), you cannot configure pf to block ICMP for an existing state. Does setting MSS on PPP and therefore MTU affect this? Setting a max-mss via pf has little to do with ICMP. Do I need to explicitly allow ICMP to enable this behaviour? No--see above.
kill a stale user session?
Hello all, I'd like to kill an stale user session, but could not find a way to do that. Seems like there is no process attached to that ttyp4 any more. It's an OpenBSD 5.1 on i386, by the way. Any advice appreciated. some output, more will be provided if necessary. #w 7:44PM up 12 days, 23:19, 2 users, load averages: 0.10, 0.14, 0.18 USERTTY FROM LOGIN@ IDLE WHAT acheng p0 180.116.63.38 6:00PM 0 w acheng p4 114.227.123.110 27Jul12 9days - -- the one I'd like to kill #ps -t p4 PID TT STAT TIME COMMAND thanks. acheng
Re: getty
On 08/05/12 07:14, Friedrich Locke wrote: I would like to change /etc/ttys to get, for instance: ttyC3 /usr/libexec/getty std.192600 vt220 on secure instead of : ttyC3 /usr/libexec/getty std.9600 vt220 on secure Why? This is not a serial console. (for those that missed it, on a i386/amd64 with onboard video and keyboard, this is what you get on console CTRL-ALT-F4.) Do you think i could run into problems ? Thanks in advance. Here's a knob I don't understand, let's give it a big hard twist. What could happen? Ok, better question: when it won't do what you presumably want (faster console I/O), why are you twiddling with knobs? If you think your VGA is running at 9600bps, either you have a really really slow computer, or more likely (as I have a 25mhz 486, and it throws text on the screen much faster than 9600bps), you don't know what 9600bps looks like (I have used 9600bps consoles. Not at all unusable, but never confused for a VGA adapter). Just...leave it alone. don't touch. Btw: this WILL cause some (hopefully, minor) issues when upgrading. Again: when faced with ZERO benefit, don't take minimal harm. Nick.
Re: kill a stale user session?
Try this? ps aux|fgrep acheng@ttyp3 On Mon, Aug 06, 2012 at 10:56:00AM +0800, Alan Cheng wrote: Hello all, I'd like to kill an stale user session, but could not find a way to do that. Seems like there is no process attached to that ttyp4 any more. It's an OpenBSD 5.1 on i386, by the way. Any advice appreciated. some output, more will be provided if necessary. #w 7:44PM up 12 days, 23:19, 2 users, load averages: 0.10, 0.14, 0.18 USERTTY FROM LOGIN@ IDLE WHAT acheng p0 180.116.63.38 6:00PM 0 w acheng p4 114.227.123.110 27Jul12 9days - -- the one I'd like to kill #ps -t p4 PID TT STAT TIME COMMAND thanks. acheng
Re: kill a stale user session?
On Mon, Aug 06, 2012 at 01:38:27PM +1000, David Diggles wrote: Try this? ps aux|fgrep acheng@ttyp3 ps aux|fgrep acheng@ttyp4 do you get the sshd process id you can kill? On Mon, Aug 06, 2012 at 10:56:00AM +0800, Alan Cheng wrote: Hello all, I'd like to kill an stale user session, but could not find a way to do that. Seems like there is no process attached to that ttyp4 any more. It's an OpenBSD 5.1 on i386, by the way. Any advice appreciated. some output, more will be provided if necessary. #w 7:44PM up 12 days, 23:19, 2 users, load averages: 0.10, 0.14, 0.18 USERTTY FROM LOGIN@ IDLE WHAT acheng p0 180.116.63.38 6:00PM 0 w acheng p4 114.227.123.110 27Jul12 9days - -- the one I'd like to kill #ps -t p4 PID TT STAT TIME COMMAND thanks. acheng
Re: ypldap
On Sun, Aug 5, 2012 at 3:11 PM, Friedrich Locke friedrich.lo...@gmail.com wrote: will ypldap serve normall files (but group and passwd) just like ypserv ? I mean: amd.home, ethers, etc . Oddly, a search for 'map' in ypldap.conf(5) answers that question with a list of the currently implemented maps. Philip Guenther
Re: kill a stale user session?
Got nothing from ps aux|fgrep acheng@ttyp4. No SSHD process to kill either. The problem for me is that no process belongs to ttyp4, but w still reports an idle session. FYI: $ ps aux|fgrep acheng@ttyp4 $ w 9:57PM up 13 days, 1:31, 3 users, load averages: 0.16, 0.18, 0.23 USERTTY FROM LOGIN@ IDLE WHAT acheng p0 180.116.63.38 6:00PM 1:50 -ksh acheng p1 114.227.120.208:06PM 0 w acheng p4 114.227.123.110 27Jul12 9days - $ ps aux | grep ksh acheng 13452 0.0 0.1 548 500 p0 Is 6:00PM0:00.02 -ksh (ksh) root 25705 0.0 0.1 632 528 p0 I+ 6:07PM0:00.07 -ksh (ksh) acheng 30721 0.0 0.1 480 488 p1 Ss 8:06PM0:00.02 -ksh (ksh) acheng 28924 0.0 0.0 480 4 p1 R+ 9:57PM0:00.00 -ksh (ksh) $ ps aux | grep sshd root 16212 0.0 0.2 656 1208 ?? Is23Jul120:04.01 /usr/sbin/sshd root 30292 0.0 0.5 3456 2812 ?? Is 6:00PM0:00.07 sshd: acheng [priv] (sshd) acheng9594 0.0 0.7 4724 3612 ?? I 6:00PM0:02.20 sshd: acheng@ttyp0 (sshd) root 22538 0.0 0.5 3428 2828 ?? Is 8:06PM0:00.06 sshd: acheng [priv] (sshd) acheng 18141 0.0 0.6 3880 2920 ?? S 8:06PM0:02.19 sshd: acheng@ttyp1 (sshd) Thanks for the response. acheng On Mon, Aug 6, 2012 at 11:42 AM, David Diggles da...@elven.com.au wrote: On Mon, Aug 06, 2012 at 01:38:27PM +1000, David Diggles wrote: Try this? ps aux|fgrep acheng@ttyp3 ps aux|fgrep acheng@ttyp4 do you get the sshd process id you can kill? On Mon, Aug 06, 2012 at 10:56:00AM +0800, Alan Cheng wrote: Hello all, I'd like to kill an stale user session, but could not find a way to do that. Seems like there is no process attached to that ttyp4 any more. It's an OpenBSD 5.1 on i386, by the way. Any advice appreciated. some output, more will be provided if necessary. #w 7:44PM up 12 days, 23:19, 2 users, load averages: 0.10, 0.14, 0.18 USERTTY FROM LOGIN@ IDLE WHAT acheng p0 180.116.63.38 6:00PM 0 w acheng p4 114.227.123.110 27Jul12 9days - -- the one I'd like to kill #ps -t p4 PID TT STAT TIME COMMAND thanks. acheng
Re: kill a stale user session?
http://marc.info/?l=openbsd-miscm=104862612011751w=2 --- List: openbsd-misc Subject:Re: Can't disconnect ghost SSH session from days ago From: Mathieu Sauve-Frankel m.sauve () secureops ! com Date: 2003-03-25 20:59:44 man utmp This ghost user is merely a stale entry in /var/run/utmp that has not been removed because your ssh session died uncleanly. Reboot your server cleanly and the ghost utmp entry will disappear. On Mon, Aug 06, 2012 at 01:00:15PM +0800, Alan Cheng wrote: Got nothing from ps aux|fgrep acheng@ttyp4. No SSHD process to kill either. The problem for me is that no process belongs to ttyp4, but w still reports an idle session. FYI: $ ps aux|fgrep acheng@ttyp4 $ w 9:57PM up 13 days, 1:31, 3 users, load averages: 0.16, 0.18, 0.23 USERTTY FROM LOGIN@ IDLE WHAT acheng p0 180.116.63.38 6:00PM 1:50 -ksh acheng p1 114.227.120.208:06PM 0 w acheng p4 114.227.123.110 27Jul12 9days - $ ps aux | grep ksh acheng 13452 0.0 0.1 548 500 p0 Is 6:00PM0:00.02 -ksh (ksh) root 25705 0.0 0.1 632 528 p0 I+ 6:07PM0:00.07 -ksh (ksh) acheng 30721 0.0 0.1 480 488 p1 Ss 8:06PM0:00.02 -ksh (ksh) acheng 28924 0.0 0.0 480 4 p1 R+ 9:57PM0:00.00 -ksh (ksh) $ ps aux | grep sshd root 16212 0.0 0.2 656 1208 ?? Is23Jul120:04.01 /usr/sbin/sshd root 30292 0.0 0.5 3456 2812 ?? Is 6:00PM0:00.07 sshd: acheng [priv] (sshd) acheng9594 0.0 0.7 4724 3612 ?? I 6:00PM0:02.20 sshd: acheng@ttyp0 (sshd) root 22538 0.0 0.5 3428 2828 ?? Is 8:06PM0:00.06 sshd: acheng [priv] (sshd) acheng 18141 0.0 0.6 3880 2920 ?? S 8:06PM0:02.19 sshd: acheng@ttyp1 (sshd) Thanks for the response. acheng On Mon, Aug 6, 2012 at 11:42 AM, David Diggles da...@elven.com.au wrote: On Mon, Aug 06, 2012 at 01:38:27PM +1000, David Diggles wrote: Try this? ps aux|fgrep acheng@ttyp3 ps aux|fgrep acheng@ttyp4 do you get the sshd process id you can kill? On Mon, Aug 06, 2012 at 10:56:00AM +0800, Alan Cheng wrote: Hello all, I'd like to kill an stale user session, but could not find a way to do that. Seems like there is no process attached to that ttyp4 any more. It's an OpenBSD 5.1 on i386, by the way. Any advice appreciated. some output, more will be provided if necessary. #w 7:44PM up 12 days, 23:19, 2 users, load averages: 0.10, 0.14, 0.18 USERTTY FROM LOGIN@ IDLE WHAT acheng p0 180.116.63.38 6:00PM 0 w acheng p4 114.227.123.110 27Jul12 9days - -- the one I'd like to kill #ps -t p4 PID TT STAT TIME COMMAND thanks. acheng
Re: kill a stale user session?
Ah ha, I searched marc.info earlier, but my key word did not found that thread. Now I know how it happened and how to fix it. Thanks David. On Mon, Aug 6, 2012 at 1:17 PM, David Diggles da...@elven.com.au wrote: http://marc.info/?l=openbsd-miscm=104862612011751w=2 --- List: openbsd-misc Subject:Re: Can't disconnect ghost SSH session from days ago From: Mathieu Sauve-Frankel m.sauve () secureops ! com Date: 2003-03-25 20:59:44 man utmp This ghost user is merely a stale entry in /var/run/utmp that has not been removed because your ssh session died uncleanly. Reboot your server cleanly and the ghost utmp entry will disappear. On Mon, Aug 06, 2012 at 01:00:15PM +0800, Alan Cheng wrote: Got nothing from ps aux|fgrep acheng@ttyp4. No SSHD process to kill either. The problem for me is that no process belongs to ttyp4, but w still reports an idle session. FYI: $ ps aux|fgrep acheng@ttyp4 $ w 9:57PM up 13 days, 1:31, 3 users, load averages: 0.16, 0.18, 0.23 USERTTY FROM LOGIN@ IDLE WHAT acheng p0 180.116.63.38 6:00PM 1:50 -ksh acheng p1 114.227.120.208:06PM 0 w acheng p4 114.227.123.110 27Jul12 9days - $ ps aux | grep ksh acheng 13452 0.0 0.1 548 500 p0 Is 6:00PM0:00.02 -ksh (ksh) root 25705 0.0 0.1 632 528 p0 I+ 6:07PM0:00.07 -ksh (ksh) acheng 30721 0.0 0.1 480 488 p1 Ss 8:06PM0:00.02 -ksh (ksh) acheng 28924 0.0 0.0 480 4 p1 R+ 9:57PM0:00.00 -ksh (ksh) $ ps aux | grep sshd root 16212 0.0 0.2 656 1208 ?? Is23Jul120:04.01 /usr/sbin/sshd root 30292 0.0 0.5 3456 2812 ?? Is 6:00PM0:00.07 sshd: acheng [priv] (sshd) acheng9594 0.0 0.7 4724 3612 ?? I 6:00PM0:02.20 sshd: acheng@ttyp0 (sshd) root 22538 0.0 0.5 3428 2828 ?? Is 8:06PM0:00.06 sshd: acheng [priv] (sshd) acheng 18141 0.0 0.6 3880 2920 ?? S 8:06PM0:02.19 sshd: acheng@ttyp1 (sshd) Thanks for the response. acheng On Mon, Aug 6, 2012 at 11:42 AM, David Diggles da...@elven.com.au wrote: On Mon, Aug 06, 2012 at 01:38:27PM +1000, David Diggles wrote: Try this? ps aux|fgrep acheng@ttyp3 ps aux|fgrep acheng@ttyp4 do you get the sshd process id you can kill? On Mon, Aug 06, 2012 at 10:56:00AM +0800, Alan Cheng wrote: Hello all, I'd like to kill an stale user session, but could not find a way to do that. Seems like there is no process attached to that ttyp4 any more. It's an OpenBSD 5.1 on i386, by the way. Any advice appreciated. some output, more will be provided if necessary. #w 7:44PM up 12 days, 23:19, 2 users, load averages: 0.10, 0.14, 0.18 USERTTY FROM LOGIN@ IDLE WHAT acheng p0 180.116.63.38 6:00PM 0 w acheng p4 114.227.123.110 27Jul12 9days - -- the one I'd like to kill #ps -t p4 PID TT STAT TIME COMMAND thanks. acheng
