Re: 4.9 errata page
> I noticed that there is nothing on the 4.9 errata page, where as in > every preceding version, there would have been several errata/patches > by now. Is it the case that there are in fact no errata, or has the > page just not been updated? So far there hasn't been anything serious enough for an errata. That's a good thing, right?
4.9 errata page
I noticed that there is nothing on the 4.9 errata page, where as in every preceding version, there would have been several errata/patches by now. Is it the case that there are in fact no errata, or has the page just not been updated?
Re: Laffs with Lennart
> On Sat, Jul 16, 2011 at 5:22 PM, Theo de Raadt > wrote: > >> It does look like an open source result of some talented people, not > >> an OpenBSD or BSD specific result. > > > > OpenSSH happened as a *direct result* of the types of decisions that > > OpenBSD developers make. > > Hi, Theo. That would be a compelling point if those decisions were > automatically good ones. Simply being "the types of decisions that > OpenBSD developers make" is not automatically a selling point, as > evidenced by the relatively small market share of OpenBSD itself. I'm > gong to dig into some history here. > > The result of "the types of decisions that OpenBSD developers make" > are precisely why it is marginalized. The core technology is robust > and excellent, but the featureset is not only limited, but actively > dangerous. I'll explain why: this gots into some serious way-back > history, but I'm not seeing any change. Fascinating. > First is the amazing foolishness of having the default key generators > accept blank passphrases without even requiring a special command line > option. Second is lack of a reliable key expiration mechanism. Once a > blank passphrase is in use, clearing them up is very difficult to > detect and very awkward to revoke the keys. These are deadly aspects > of the SSH protocol and toolkits that could, and should, have been > addressed a decade ago, even before OpenSSH existed. The result is > that I've personally had one hell of a time getting people off of less > technologically secure tools, such as HTTPS access for Subverson which > stores passwords in clear text on UNIX and Linux clients. This tool > has SSH based access available to avoid the UNIX or Linux client > password storage of HTTPS, but lacks an integral chroot cage or > dedicated shell to restrict the users: the results are various weird, > homegrown integrations. (Sourceforge uses one, and it's messy due to > the lack of chroot cage compatible integration for Subversion.) Git > does a better job of this, by the way, which is a good reason to > prefer it. Wow, it's a real bummer that OpenBSD has caused you so much harm. Have you considered trying to live 100% without our software? Of course, if you did that, you'd have to keep your mouth shut, wouldn't you. That does not seem in your nature.. > But I've dealt with 6 such source control integration efforts in > the last 5 years, and it's painful to deal with the passphrase free > keys and having to hand-build an expiration mechanism *eveyr single > time*, even if I do keep my old notes. This could be eased by client > side software changes, such as refusing to accept a blank password > without a special command line option or user privilege, or even a > setting in ssh_config to block such behavior. If a client can override > that, then it's their problem, but the lack of any significant barrier > to generating such keys is a long standing issue I've had to clean up > after again, and again, and again. Your pain runs very deep. Have you considered suicide? > This is compounded by the longstanding refusal to accept chroot cage > integration for SSH or SCP. (Yes, it's me: I was one of the people > publishing such patches over a decade ago.) Debian has actually > provided some tools for helping set that up, Ah, yes, Debian. They have an amazing history when it comes to patching our code good luck with that. > and they're quite useful > for at least raising the bar for clients with locally authorized > access to escape their cages. SFTP does a better job of it, and its > relatively new built-in chroot cages are welcome. But the chroot cages > for SSH are long-desired for Subversion and CVS repository access, and > software regression testing environments. (By the way, the better > security models of "git" with its dedicated shell and good key > management tools well justify switching to it from CVS or Subversion, > along with its vastly better "merge" behavior.) > > If we couple all of those decisions, mostly policy decisions, with the > longstanding incapability to transfer symlinks as symlinks, rather > than as the targets of the symlink, by both SFTP and SCP, and the > direct result of those decisions doesn't look so hot, even though the > underlying protocol and implementation in OpenSSH have much to > recommend them. Your grief would seem more sincere if didn't look like a shopping list. Except your name or those you work for do not occur in the donations list or anywhere else... > This last one is actually built into the RFC's, but if > a new RFC is needed, then it's about time. We don't author the RFC. But thanks for trying to make us responsible for that, too. Pray tell, what are you responsible for, besides bitching out other people's efforts? > The result is that I'd *rather* trust the end-to-end encryption of the > underlying SSH protocol. But the missing basic security features, > whose absence is either tacitly accepted (such as making pa
Re: Laffs with Lennart
On Sat, Jul 16, 2011 at 5:22 PM, Theo de Raadt wrote: >> It does look like an open source result of some talented people, not >> an OpenBSD or BSD specific result. > > OpenSSH happened as a *direct result* of the types of decisions that > OpenBSD developers make. Hi, Theo. That would be a compelling point if those decisions were automatically good ones. Simply being "the types of decisions that OpenBSD developers make" is not automatically a selling point, as evidenced by the relatively small market share of OpenBSD itself. I'm gong to dig into some history here. The result of "the types of decisions that OpenBSD developers make" are precisely why it is marginalized. The core technology is robust and excellent, but the featureset is not only limited, but actively dangerous. I'll explain why: this gots into some serious way-back history, but I'm not seeing any change. First is the amazing foolishness of having the default key generators accept blank passphrases without even requiring a special command line option. Second is lack of a reliable key expiration mechanism. Once a blank passphrase is in use, clearing them up is very difficult to detect and very awkward to revoke the keys. These are deadly aspects of the SSH protocol and toolkits that could, and should, have been addressed a decade ago, even before OpenSSH existed. The result is that I've personally had one hell of a time getting people off of less technologically secure tools, such as HTTPS access for Subverson which stores passwords in clear text on UNIX and Linux clients. This tool has SSH based access available to avoid the UNIX or Linux client password storage of HTTPS, but lacks an integral chroot cage or dedicated shell to restrict the users: the results are various weird, homegrown integrations. (Sourceforge uses one, and it's messy due to the lack of chroot cage compatible integration for Subversion.) Git does a better job of this, by the way, which is a good reason to prefer it. But I've dealt with 6 such source control integration efforts in the last 5 years, and it's painful to deal with the passphrase free keys and having to hand-build an expiration mechanism *eveyr single time*, even if I do keep my old notes. This could be eased by client side software changes, such as refusing to accept a blank password without a special command line option or user privilege, or even a setting in ssh_config to block such behavior. If a client can override that, then it's their problem, but the lack of any significant barrier to generating such keys is a long standing issue I've had to clean up after again, and again, and again. This is compounded by the longstanding refusal to accept chroot cage integration for SSH or SCP. (Yes, it's me: I was one of the people publishing such patches over a decade ago.) Debian has actually provided some tools for helping set that up, and they're quite useful for at least raising the bar for clients with locally authorized access to escape their cages. SFTP does a better job of it, and its relatively new built-in chroot cages are welcome. But the chroot cages for SSH are long-desired for Subversion and CVS repository access, and software regression testing environments. (By the way, the better security models of "git" with its dedicated shell and good key management tools well justify switching to it from CVS or Subversion, along with its vastly better "merge" behavior.) If we couple all of those decisions, mostly policy decisions, with the longstanding incapability to transfer symlinks as symlinks, rather than as the targets of the symlink, by both SFTP and SCP, and the direct result of those decisions doesn't look so hot, even though the underlying protocol and implementation in OpenSSH have much to recommend them. This last one is actually built into the RFC's, but if a new RFC is needed, then it's about time. The result is that I'd *rather* trust the end-to-end encryption of the underlying SSH protocol. But the missing basic security features, whose absence is either tacitly accepted (such as making passphrase keys more difficult to use), or a matter of deliberate policy (such as refusal to work with chroot cages for SSH or SCP) have seriuosly impeded the use and security of OpenSSH itself. So I have some longstanding, and I think well-founded, concerns about "the types of decisions that OpenBSD developers make".
pf: state key linking mismatch (?)
hi all: I'm getting tons of messages like this one: pf: state key linking mismatch! dir=OUT, if=vr1, stored af=2, a0: 83.237.186.131:51413, a1: 192.168.1.2:64768, proto=17, found af=2, a0: 192.168.1.2:64768, a1: 181.110.135.229:51413, proto=17 The public 'a1' address (181.110.135.229) is repeated always but does not much my real public interface address. The rule is probably related with this line: @41 pass in on vr0 inet proto tcp from any to (vr0:1) port = 64768 flags S/SA synproxy state (max 50, adaptive.start 30, adaptive.end 60) tag VR0_TAG rdr-to 192.168.1.2 port 64768 Can someone enlighten me what does this means? TIA!
Re: Laffs with Lennart
> It does look like an open source result of some talented people, not > an OpenBSD or BSD specific result. OpenSSH happened as a *direct result* of the types of decisions that OpenBSD developers make.
Re: How does OpenBSD compare to Ubuntu Server?
On Mon, Jul 11, 2011 at 8:16 PM, J Sisson wrote: > On Mon, Jul 11, 2011 at 6:58 PM, Juan Miscaro wrote: > >> On 7 July 2011 15:06, jirib wrote: >> >> Are you kidding? Ubuntu? Where installed daemons are running by default, >> > where there is no command to disable shitty upstart daemons? >> >> Which daemons are those again? >> >> apt-get install > > Oh look, is running before I have a chance to > configure it and lock it down the way I see fit. Good thing we all > know those Ubuntu/Debian guys are so damned smart and all... Far too many daemons are installed by default on Ubuntu. It's a "give people everything they might desire some day" approach, rather than a "keep it stable by giving them only what they need and ask for". This is particularly evidenced by plethora of 3rd party repositories with fascinating components that are easily merged into Ubuntu, and require more manual integration and local compilation with OpenBSD. And the reliance on older, stable, well-debugged components makes leading edge development of Java and web apps more awkard in OpenBSD. But OpenBSD is vastly more secure and avoids craziness such as NetworkManager and 3 million useless and poorly implemented web proxies and "chat" servers.
Re: Laffs with Lennart
On Sat, Jul 16, 2011 at 1:32 PM, Chris Cappuccio wrote: > Nico Kadel-Garcia [nka...@gmail.com] wrote: >> >> Don't mistake OpenSSH for OpenBSD. The early history is fascinating. >> >> http://docstore.mik.ua/orelly/networking_2ndEd/ssh/ch01_05.htm >> >> (I was involved in very early SunOS ports of ssh-1 and ssh-2, before >> OpenSSH existed.) > > Most of the early history isn't even relevant to OpenSSH or to the world that uses OpenSSH because it involves ssh-2. OpenSSH took the last free version of ssh-1 and radically transformed it. > > Despite ssh-1 and ssh-2 being supported on a variety of platforms, none could include it because of the commercial license. > > Tatu's goal was to operate a commercial enterprise, but the goal with OpenSSH was to replace telnet. In the end, everyone got what they wanted, even if OpenSSH forced the commercial version to an enterprise niche, serving large environments with odd authentication systems It does look like an open source result of some talented people, not an OpenBSD or BSD specific result. I'm just saying, don't confuse the usefulness and ubiquity of OpenSSH with the mental market share or relevance of the rest of OpenBSD or other BSD's.
Re: Laffs with Lennart
Nico Kadel-Garcia [nka...@gmail.com] wrote: > > Don't mistake OpenSSH for OpenBSD. The early history is fascinating. > > http://docstore.mik.ua/orelly/networking_2ndEd/ssh/ch01_05.htm > > (I was involved in very early SunOS ports of ssh-1 and ssh-2, before > OpenSSH existed.) Most of the early history isn't even relevant to OpenSSH or to the world that uses OpenSSH because it involves ssh-2. OpenSSH took the last free version of ssh-1 and radically transformed it. Despite ssh-1 and ssh-2 being supported on a variety of platforms, none could include it because of the commercial license. Tatu's goal was to operate a commercial enterprise, but the goal with OpenSSH was to replace telnet. In the end, everyone got what they wanted, even if OpenSSH forced the commercial version to an enterprise niche, serving large environments with odd authentication systems
timing borked with last sparc64 snapshot
Hello, today I was updating to the latest snapshot on sparc64 on a SUN Blade 100. While installing the sets all looked normal until after the base49.tgz set. The progress bar stayed for a while at 0%, then suddenly jumped to 100%. That's why the time is displayed as 00:00: Set name(s)? (or 'abort' or 'done') [done] bsd 100% |*| 7339 KB00:02 bsd.rd 100% |*| 2597 KB00:00 base49.tgz 100% |*| 57926 KB00:16 comp49.tgz 100% |*| 64997 KB00:00 man49.tgz100% |*| 9495 KB00:00 game49.tgz 100% |*| 2709 KB00:00 xbase49.tgz 100% |*| 12144 KB00:00 xshare49.tgz 100% |*| 3353 KB00:00 xfont49.tgz 100% |*| 38485 KB00:00 xserv49.tgz 100% |*| 6374 KB00:00 Location of sets? (cd disk ftp http or 'done') [done] Before rebooting the system running 'date' several times always display the same time for a long time. After more than 30min I gave up. Running reboot does take very long. After a long time I did a Ctrl-C, unmounted all the drives under /mnt and powercycled the machine. After booting the machine, the boot seems to hang at: starting network daemons: sshd sendmail inetd. starting local daemons:. standard daemons: cron. Sat Jul 16 18:05:12 CEST 2011 Machine responds to pings. SSH login is kind of possible. If I press Ctrl-C after the usual login message I could get a shell prompt. $ date Sat Jul 16 18:05:14 CEST 2011 $ date Sat Jul 16 18:05:14 CEST 2011 $ date Sat Jul 16 18:05:13 CEST 2011 $ date Sat Jul 16 18:05:13 CEST 2011 $ date Sat Jul 16 18:05:13 CEST 2011 Time seems not really reliable here... snapshot is from July 16th. The one from June 29th was working fine. Any hints how to resolve this? Anything to test? With the older snapshot the machine works without problems. Regards, Markus
Re: VoIP products for SMBs
Dear PM, I would like to introduce Yeastar Technology. Supporting VoIP Solution Providers in more than 30 countries, Yeastar Technology has been providing feature rich VoIP PBX for SMBs since 2008. IP PBX from Yeastar is modular, scalable and flexible. This gives clients the opportunity to customize solutions to their needs. MyPBX serial supports PSTN, GSM, SIP (IAX2) trunks with FXS / FXO/ E1 PRI/GSM/ BRI (ISDN) ports. It is embedded hybrid IP-PBX which caters for the small businesses. Should any of these items be of interest to you, please let us know. We will be happy to give you a quotation upon receipt of your detailed requirements. Sincerely, Jessica - --- Yeastar. Sales Manager Yeastar Technology Co.,Ltd. Room 202,No. 23 Wanghai Road,2nd Software Park,Xiamen,China Phon.: 86-592-5503309 Ext.5003 Fax: 86-592-5503307 Website: http://www.yeastar.cn Email: sa...@yeastar.cn Skype ID: yeastar.sales If you would like to receive our newsletters to get more idea of our products, please click here. Don't want to receive these newsletters anymore?please click here [demime 1.01d removed an attachment of type image/jpeg which had a name of MyPBX-Pro-02.jpg]
Re: Very strange cvs performance.
On Sat, Jul 16, 2011 at 01:12:57PM +0200, Claudio Jeker wrote: > On Sat, Jul 16, 2011 at 03:16:29AM -0300, Christiano F. Haesbaert wrote: > > Hi there, I have a local mirror of cvs src, everything works fine, except > > that > > the IO seems to take place in another disk. > > > > I have a very very very very slow udma controller in wd0 (the ultra 5 one): > > > > wd0(pciide0:0:0): using PIO mode 4, DMA mode 2 > > > > So I keep my cvs in a faster controller/disk: > > > > wd1(pciide1:2:0): using BIOS timings, Ultra-DMA mode 7 > > > > I have this, so you can see, most stuff is on the slow controller. > > > > /dev/wd0a on / type ffs (local) > > /dev/wd0d on /tmp type ffs (local, nodev, nosuid) > > /dev/wd0g on /usr type ffs (NFS exported, local, nodev) > > /dev/wd0e on /var type ffs (local, nodev, nosuid) > > /dev/wd1a on /data/sta type ffs (NFS exported, local, nodev, nosuid) > > > > Here is the weird part, /cvs points to /data/sta/cvs (which is in the fast > > controller) > > > > lrwxr-xr-x 1 root wheel 14 Jul 13 19:55 cvs@ -> /data/sta/cvs/ > > > > Now watch what happends when I 'cvs up' from another machine: > > > > == No cvs up, disk mostly idle == > > > > gandalf:haesbaert: iostat -w 3 > > ttywd0 cd0 wd1 cpu > > tin tout KB/t t/s MB/s KB/t t/s MB/s KB/t t/s MB/s us ni sy in id > >0 41 11.68 3 0.03 0.00 0 0.00 49.91 5 0.25 1 0 2 1 96 > >0 74 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 0 0100 > >0 98 13.71 7 0.09 0.00 0 0.00 0.00 0 0.00 0 0 0 0100 > > > > == cvs up, wd1 transaction should go up roof == > > gandalf:haesbaert: iostat -w 3 > > ttywd0 cd0 wd1 cpu > > tin tout KB/t t/s MB/s KB/t t/s MB/s KB/t t/s MB/s us ni sy in id > >0 41 11.68 3 0.03 0.00 0 0.00 49.91 5 0.25 1 0 2 1 96 > >0 98 9.52 263 2.45 0.00 0 0.00 0.00 0 0.00 5 0 9 3 84 > >0 25 9.53 277 2.58 0.00 0 0.00 0.00 0 0.00 1 0 5 0 94 > >0 49 9.51 282 2.62 0.00 0 0.00 0.00 0 0.00 2 0 7 1 90 > >0 49 9.67 258 2.44 0.00 0 0.00 64.00 0 0.02 1 0 5 1 93 > > > > > > But no, IO seems to take place mostly in wd0, I've confirmed swap was not > > taking > > place, I shut down everything, top showed 100mb+ free: > > > > load averages: 2.23, 1.02, 0.65 > > gandalf.midearth 03:12:25 > > 42 processes: 1 running, 40 idle, 1 on processor > > CPU states: 1.6% user, 0.0% nice, 4.9% system, 0.4% interrupt, 93.2% > > idle > > Memory: Real: 19M/64M act/tot Free: 176M Swap: 16M/1024M used/tot > > > > The user doing the cvs has a home in /home/ which is in wd0. > > I'm also able to hear wd0 (different sound than wd1), so I know fstat is > > telling > > the truth. > > > > What's hapenning ? I'm pretty sure I'm missing something real simple, just > > to have > > an insight, a 'cvs up' is taking more than 30min. > > > > cvs is also using /tmp which is on wd0 for temporary files. > There it is, thank you ! -- Christiano Farina HAESBAERT Do NOT send me html mail.
Re: Laffs with Lennart
Lennart is a funny, funny man, go check the avahi code to see how nice it is. " When working on Avahi I learned a lot about the complexities of safely and reliably running and maintaining system services, and about securing them as much as possible, which is particularly important for network facing services like Avahi. I implemented a lot of pretty nifty features in this area in Avahi. For example, Avahi is still pretty much the *only daemon* on a standard Linux install that chroot()s itself by default. " -- Christiano Farina HAESBAERT Do NOT send me html mail.
Re: Laffs with Lennart
On Sat, Jul 16, 2011 at 12:37:57PM +, Jona Joachim wrote: > On 2011-07-16, Chris Cappuccio wrote: > > Lennart Poettering has graced the world with his brilliance one more time. > > Why? Lennart doesn't "think BSD is too relevant anymore." > [nolog] > > This is nothing new, it has been anticipated by BSD developers a long time > ago: > http://talks.dixongroup.net/nycbsdcon2006/ Indeed, I've been proclaiming BSD dead for the last five years. Get with the times. -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net/
Re: Laffs with Lennart
On Sat, Jul 16, 2011 at 6:40 AM, Peter N. M. Hansteen wrote: > Chris Cappuccio writes: > >> Lennart Poettering has graced the world with his brilliance one more >> time. Why? Lennart doesn't "think BSD is too relevant anymore." >> >> http://linuxfr.org/nodes/86687/comments/1249943 > > It would be almost tempting to ask if he uses ssh much and if so which > one, but I'm not sure I'd bother. Don't mistake OpenSSH for OpenBSD. The early history is fascinating. http://docstore.mik.ua/orelly/networking_2ndEd/ssh/ch01_05.htm (I was involved in very early SunOS ports of ssh-1 and ssh-2, before OpenSSH existed.)
Вас пригласили зарегестрироваться
]rn ohq|ln nr B`xecn dpsc` Ivko. B`q ophck`x`~r g`peceqrphpnb`r|q : http://alturl.com/y9rnn Ophber. _ pe`k|mn g` 7 dmei g`p`anr`k 132 EUR!!!
Re: Laffs with Lennart
On 2011-07-16, Chris Cappuccio wrote: > Lennart Poettering has graced the world with his brilliance one more time. > Why? Lennart doesn't "think BSD is too relevant anymore." [nolog] This is nothing new, it has been anticipated by BSD developers a long time ago: http://talks.dixongroup.net/nycbsdcon2006/ Best regards, Jona -- Pond-erosa Puff wouldn't take no guff Water oughta be clean and free So he fought the fight and he set things right With his OpenBSD
Re: Laffs with Lennart
On Sat, 16 Jul 2011 12:40:47 +0200, Peter N. M. Hansteen wrote: >Chris Cappuccio writes: >> Lennart Poettering has graced the world with his brilliance one more >> time. Why? Lennart doesn't "think BSD is too relevant anymore." >> >> http://linuxfr.org/nodes/86687/comments/1249943 >It would be almost tempting to ask if he uses ssh much and if so which >one, but I'm not sure I'd bother. >- P And a lot of linux users bagged him on /. None too happy about replacing ALSA with his own toy. Not often would I point you at /. but here is the exception. http://bsd.slashdot.org/story/11/07/16/0020243/Lennart-Poettering-BSD-Isnt-Relevant-Anymore R/ *** NOTE *** Please DO NOT CC me. I subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it.
Re: Very strange cvs performance.
On Sat, Jul 16, 2011 at 03:16:29AM -0300, Christiano F. Haesbaert wrote: > Hi there, I have a local mirror of cvs src, everything works fine, except that > the IO seems to take place in another disk. > > I have a very very very very slow udma controller in wd0 (the ultra 5 one): > > wd0(pciide0:0:0): using PIO mode 4, DMA mode 2 > > So I keep my cvs in a faster controller/disk: > > wd1(pciide1:2:0): using BIOS timings, Ultra-DMA mode 7 > > I have this, so you can see, most stuff is on the slow controller. > > /dev/wd0a on / type ffs (local) > /dev/wd0d on /tmp type ffs (local, nodev, nosuid) > /dev/wd0g on /usr type ffs (NFS exported, local, nodev) > /dev/wd0e on /var type ffs (local, nodev, nosuid) > /dev/wd1a on /data/sta type ffs (NFS exported, local, nodev, nosuid) > > Here is the weird part, /cvs points to /data/sta/cvs (which is in the fast > controller) > > lrwxr-xr-x 1 root wheel 14 Jul 13 19:55 cvs@ -> /data/sta/cvs/ > > Now watch what happends when I 'cvs up' from another machine: > > == No cvs up, disk mostly idle == > > gandalf:haesbaert: iostat -w 3 > ttywd0 cd0 wd1 cpu > tin tout KB/t t/s MB/s KB/t t/s MB/s KB/t t/s MB/s us ni sy in id >0 41 11.68 3 0.03 0.00 0 0.00 49.91 5 0.25 1 0 2 1 96 >0 74 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 0 0100 >0 98 13.71 7 0.09 0.00 0 0.00 0.00 0 0.00 0 0 0 0100 > > == cvs up, wd1 transaction should go up roof == > gandalf:haesbaert: iostat -w 3 > ttywd0 cd0 wd1 cpu > tin tout KB/t t/s MB/s KB/t t/s MB/s KB/t t/s MB/s us ni sy in id >0 41 11.68 3 0.03 0.00 0 0.00 49.91 5 0.25 1 0 2 1 96 >0 98 9.52 263 2.45 0.00 0 0.00 0.00 0 0.00 5 0 9 3 84 >0 25 9.53 277 2.58 0.00 0 0.00 0.00 0 0.00 1 0 5 0 94 >0 49 9.51 282 2.62 0.00 0 0.00 0.00 0 0.00 2 0 7 1 90 >0 49 9.67 258 2.44 0.00 0 0.00 64.00 0 0.02 1 0 5 1 93 > > > But no, IO seems to take place mostly in wd0, I've confirmed swap was not > taking > place, I shut down everything, top showed 100mb+ free: > > load averages: 2.23, 1.02, 0.65 > gandalf.midearth 03:12:25 > 42 processes: 1 running, 40 idle, 1 on processor > CPU states: 1.6% user, 0.0% nice, 4.9% system, 0.4% interrupt, 93.2% idle > Memory: Real: 19M/64M act/tot Free: 176M Swap: 16M/1024M used/tot > > The user doing the cvs has a home in /home/ which is in wd0. > I'm also able to hear wd0 (different sound than wd1), so I know fstat is > telling > the truth. > > What's hapenning ? I'm pretty sure I'm missing something real simple, just to > have > an insight, a 'cvs up' is taking more than 30min. > cvs is also using /tmp which is on wd0 for temporary files. -- :wq Claudio
Re: Laffs with Lennart
Chris Cappuccio writes: > Lennart Poettering has graced the world with his brilliance one more > time. Why? Lennart doesn't "think BSD is too relevant anymore." > > http://linuxfr.org/nodes/86687/comments/1249943 It would be almost tempting to ask if he uses ssh much and if so which one, but I'm not sure I'd bother. - P -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Very strange cvs performance.
Hi there, I have a local mirror of cvs src, everything works fine, except that the IO seems to take place in another disk. I have a very very very very slow udma controller in wd0 (the ultra 5 one): wd0(pciide0:0:0): using PIO mode 4, DMA mode 2 So I keep my cvs in a faster controller/disk: wd1(pciide1:2:0): using BIOS timings, Ultra-DMA mode 7 I have this, so you can see, most stuff is on the slow controller. /dev/wd0a on / type ffs (local) /dev/wd0d on /tmp type ffs (local, nodev, nosuid) /dev/wd0g on /usr type ffs (NFS exported, local, nodev) /dev/wd0e on /var type ffs (local, nodev, nosuid) /dev/wd1a on /data/sta type ffs (NFS exported, local, nodev, nosuid) Here is the weird part, /cvs points to /data/sta/cvs (which is in the fast controller) lrwxr-xr-x 1 root wheel 14 Jul 13 19:55 cvs@ -> /data/sta/cvs/ Now watch what happends when I 'cvs up' from another machine: == No cvs up, disk mostly idle == gandalf:haesbaert: iostat -w 3 ttywd0 cd0 wd1 cpu tin tout KB/t t/s MB/s KB/t t/s MB/s KB/t t/s MB/s us ni sy in id 0 41 11.68 3 0.03 0.00 0 0.00 49.91 5 0.25 1 0 2 1 96 0 74 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 0 0100 0 98 13.71 7 0.09 0.00 0 0.00 0.00 0 0.00 0 0 0 0100 == cvs up, wd1 transaction should go up roof == gandalf:haesbaert: iostat -w 3 ttywd0 cd0 wd1 cpu tin tout KB/t t/s MB/s KB/t t/s MB/s KB/t t/s MB/s us ni sy in id 0 41 11.68 3 0.03 0.00 0 0.00 49.91 5 0.25 1 0 2 1 96 0 98 9.52 263 2.45 0.00 0 0.00 0.00 0 0.00 5 0 9 3 84 0 25 9.53 277 2.58 0.00 0 0.00 0.00 0 0.00 1 0 5 0 94 0 49 9.51 282 2.62 0.00 0 0.00 0.00 0 0.00 2 0 7 1 90 0 49 9.67 258 2.44 0.00 0 0.00 64.00 0 0.02 1 0 5 1 93 But no, IO seems to take place mostly in wd0, I've confirmed swap was not taking place, I shut down everything, top showed 100mb+ free: load averages: 2.23, 1.02, 0.65 gandalf.midearth 03:12:25 42 processes: 1 running, 40 idle, 1 on processor CPU states: 1.6% user, 0.0% nice, 4.9% system, 0.4% interrupt, 93.2% idle Memory: Real: 19M/64M act/tot Free: 176M Swap: 16M/1024M used/tot The user doing the cvs has a home in /home/ which is in wd0. I'm also able to hear wd0 (different sound than wd1), so I know fstat is telling the truth. What's hapenning ? I'm pretty sure I'm missing something real simple, just to have an insight, a 'cvs up' is taking more than 30min. Thanks gandalf:sta: dmesg console is /pci@1f,0/pci@1,1/ebus@1/se@14,40:a Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2011 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 4.9 (GENERIC) #241: Tue Feb 15 16:08:29 MST 2011 t...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/GENERIC real mem = 268435456 (256MB) avail mem = 251617280 (239MB) mainbus0 at root: Sun Ultra 5/10 UPA/PCI (UltraSPARC-IIi 400MHz) cpu0 at mainbus0: SUNW,UltraSPARC-IIi (rev 9.1) @ 400 MHz cpu0: physical 16K instruction (32 b/l), 16K data (32 b/l), 2048K external (64 b/l) psycho0 at mainbus0 addr 0xfffc4000: SUNW,sabre, impl 0, version 0, ign 7c0 psycho0: bus range 0-3, PCI bus 0 psycho0: dvma map c000-dfff pci0 at psycho0 ppb0 at pci0 dev 1 function 1 "Sun Simba PCI-PCI" rev 0x13 pci1 at ppb0 bus 1 ebus0 at pci1 dev 1 function 0 "Sun PCIO EBus2" rev 0x01 auxio0 at ebus0 addr 726000-726003, 728000-728003, 72a000-72a003, 72c000-72c003, 72f000-72f003 power0 at ebus0 addr 724000-724003 ivec 0x25 "SUNW,pll" at ebus0 addr 504000-504002 not configured sab0 at ebus0 addr 40-40007f ivec 0x2b: rev 3.2 sabtty0 at sab0 port 0: console sabtty1 at sab0 port 1 comkbd0 at ebus0 addr 3083f8-3083ff ivec 0x29: no keyboard comms0 at ebus0 addr 3062f8-3062ff ivec 0x2a wsmouse0 at comms0 mux 0 lpt0 at ebus0 addr 3043bc-3043cb, 30015c-30015d, 70-7f ivec 0x22: polled "fdthree" at ebus0 addr 3023f0-3023f7, 706000-70600f, 72-720003 ivec 0x27 not configured clock1 at ebus0 addr 0-1fff: mk48t59 "flashprom" at ebus0 addr 0-f not configured audioce0 at ebus0 addr 20-2000ff, 702000-70200f, 704000-70400f, 722000-722003 ivec 0x23 ivec 0x24: nvaddrs 0 audio0 at audioce0 hme0 at pci1 dev 1 function 1 "Sun HME" rev 0x01: ivec 0x7e1, address 00:03:ba:08:72:5a nsphy0 at hme0 phy 1: DP83840 10/100 PHY, rev. 1 machfb0 at pci1 dev 2 function 0 "ATI Mach64" rev 0x5c machfb0: ATY,GT-C, 1152x900 wsdisplay0 at machfb0 mux 1 wsdisplay0: screen 0 added (std, sun emulation) pciide0 at pci1 dev 3 function 0 "CMD Technology PCI0646" rev 0x03: DMA, channel 0 configured to native-PCI, channel 1 configur
