[00:13] milki: i'm about that too i think :) [00:14] 7.1 gb in the last month [01:24] *** mjp has quit IRC (Read error: Connection reset by peer) [01:25] *** mjp has joined #arpnetworks [01:38] *** Webhostbudd has quit IRC (Quit: Leaving) [02:36] beta VM guys should re-test disk I/O. I've disabled my munin graphing temporarily (turns out it was munin going crazy, not cacti) [02:37] munin will wind down in about 5 minutes [02:43] and so now there shouldn't be big load spikes [02:43] * up_the_irons leaves the data center [03:11] *** Ehtyar has joined #arpnetworks [04:15] w00t, sponsored reddit link: http://www.reddit.com/comments/11axe2/arp_networks_offers_freebsd_vps_services_with/ [04:16] i can haz upvotes?:) [04:32] toddf: are you compiling something or doing something heavy on your beta VM? (not a problem, just wondering cuz i saw it taking a bit of cpu) [04:50] *** jnq has quit IRC (Quit: WeeChat 0.3.0) [04:54] anyone know if a munin master at 2.x can be used with munin nodes that are still just 1.x ? [04:54] i want to move to 2.x for performance on the master, but i'd hate to have to also update all my nodes [04:55] up_the_irons: I've always had master and nodes on same train. It should work though. [04:56] josephb: roger [04:58] up_the_irons: tun/tap support, anything special needed? [04:59] josephb: nope [04:59] josephb: pretend it is a bare metal machine that's all yours [05:00] ta, just trying to get ipip or gre tunnel going back to home so my vps can monitor internal things [05:03] josephb: shouldn't be an issue. i see gre traffic here and there, so i know other people are doing it too ;) [05:05] unfortunately, i must dual boot into Windows now (radio programming)... [05:05] * up_the_irons walks over to the dark side [05:23] upvoted up_the_irons [05:44] *** LEMONed has joined #arpnetworks [06:00] *** LEMONed has quit IRC (Quit: !stfu) [06:32] up_the_irons: abusing it to test opensmtpd .. I think its wedged .. resetting [06:33] I started a test on friday, I guess it kinda went bezerk. [06:33] UVM: pid 30715 (procmail), uid 547 killed: out of swap [06:54] doh [07:00] yeah, until 'recent' commits this weekend, if you did 'echo "|sleep 60" > .forward' and delivered a bunch of tiny mails you'd end up with an out of fd exhaustion scenario where it falls flat on its face ... [07:01] local deliveries happened 'quickly' in any prior tests, but since I'm delivering mail via procmail and piping it through a dspam filter .. it takes a few seconds and the more that pile up, the slower it goes, circle of death ensues, etc ;-) [07:02] now there is a std default MDA limit per user and global for the system, to be tunable after the upcoming release of opensmtpd [07:08] wew [07:09] i am still on a mission to find a usable android emial client that isn't gmail [07:09] stupid conversationviewbeingawesome [07:16] qbit: 'usable' is in the eye of the beholder. ever consider writing one if you're searching in vain? [07:19] toddf: no doubt.. but building a java app of that scale is out side of my knowledge-time threshold. [07:21] even hacking on existing open source mail clients :P [07:23] *** dj_goku has joined #arpnetworks [07:23] *** dj_goku has quit IRC (Changing host) [07:23] *** dj_goku has joined #arpnetworks [08:09] toddf: There is a reason why the traditional MTA design was to queue emails at all stages and have a queue runner to process them later [08:20] plett: are you suggesting smtpd does not do it that way? [08:21] plett: it does, infact, queue all mails and then process it later, and there is a mda (mail delivery agent) process that you might consider a queue runner to process them later. it simply did a 'forkmda()' call without bounds. that is now fixed ;-) [08:39] toddf: Ahh. I didn't know opensmtpd did work that way. I read your initial comment to be that it spawned deliver processes for each email without considering how many other deliveries were already happening [08:43] apparently I was the first one to test with a procmailrc that took more than <1s to deliver ;-) [08:44] ol [08:44] l [08:56] *** jbum has quit IRC (Quit: jbum) [09:19] *** jbum has joined #arpnetworks [09:22] *** RandalSchwartz has joined #arpnetworks [09:22] * RandalSchwartz waves for no apparent reason [09:29] * toddf waves back [09:30] *** warex has joined #arpnetworks [09:31] Is there a link on how to configure the parameters of the network device? (I'm manually installing OpenBSD) [09:32] man hostname.if(5) and if you don't have an openbsd host handy see http://www.openbsd.org/cgi-bin/man.cgi?query=hostname.if [09:32] *everyone* should have an openbsd host handy. :) [09:33] bah, just use FreeBSD and get the best bits of OpenBSD :) [09:33] there's also the http://www.freebsd.org/cgi/man.cgi [09:33] which has *all* the manpages [09:33] nice resource [09:34] I'm sorry, I mean the parameters from arpnetworks to configure my network device (ipv6address, ipv4address and else) [09:34] warex: all of that's in your portal [09:34] Notably, under "IP" [09:37] oh... sorry! thanks! [10:31] *** chmod\2 has joined #arpnetworks [10:31] *** chmod\ has quit IRC (Ping timeout: 246 seconds) [10:46] *** HighJinx has quit IRC (Quit: Computer has gone to sleep.) [10:46] *** chmod\2 has quit IRC (Read error: Connection reset by peer) [10:46] *** chmod\ has joined #arpnetworks [10:57] *** Webhostbudd has joined #arpnetworks [11:04] *** _mnathani_ has joined #arpnetworks [11:04] *** HighJinx has joined #arpnetworks [11:06] *** warex has quit IRC (Ping timeout: 245 seconds) [11:16] *** dj_goku has quit IRC (Quit: leaving) [11:27] *** warex has joined #arpnetworks [11:28] is it needed to disable mpbios so OpenBSD can start its em0 networkservice? I'm trying a fresh install but em0 sends a watchdog watchdog timedout and freezes just when trying to start the network services [11:34] yes [11:58] *** HighJinx has quit IRC () [11:59] *** HighJinx has joined #arpnetworks [13:15] *** Ehtyar has quit IRC (Quit: Never look down on someone unless you're helping them up.) [15:02] mikeputnam: tnx! [15:02] toddf: ah ok [15:03] qbit: what about k-9 mail? [15:03] that's what i use [15:04] I also use K-9. It's certainly no mutt, but it's the best I've found. [15:04] up_the_irons: i wish i could set colors for specific headers [15:04] *** mjp has quit IRC (Remote host closed the connection) [15:04] and thread things by converstaion [15:04] qbit: You mean the three long bolts? [15:04] conversation too [15:04] CaZe: ya [15:05] I think I tighten them quite a bit tighter than he recommends. [15:05] I never did describe the actual alignment process, did I? [15:06] nope :D [15:07] Well, like I started saying, you have to first think about why being out of alignment causes the axle to bob up and down. [15:07] Do you know why that happens? [15:11] lol, because it's not aligned. :P - same concept as a bent axle [15:12] No, the axle is straight. [15:12] At least, it should be. [15:12] If it isn't, then you need a new axle. [15:12] i just mean in concept - not sure how else to explain it other than that [15:12] And a bent axle doesn't bob up and down parallel to its shaft anyway. [15:12] oh [15:12] then i don't know :D [15:13] Well, as Doug describes, the inner burr isn't perfectly round. [15:13] It's slightly oval. [15:14] Do you have your Pharos in front of you right now? [15:14] yep [15:15] *** mjp has joined #arpnetworks [15:15] and if i spin the axle when it's upside-down the axle bobs [15:16] Well that wouldn't happen if it were aligned, because even if the inner burr is oval, if it were perfectly centered, then the two "far" points of the oval would be scraping the outer burr, counterbalancing one another. [15:16] so it bobs because of the oval-ness of the inner burr? [15:17] It bobs because it's out of alignment. [15:17] If it's out of alignment, then that means the inner burr isn't centered. [15:18] so the burrs are hitting when it's bobbing [15:18] The burrs are always hitting when you have it upside down. [15:19] The burrs are the only thing that keeps the axles from sliding out of the apparatus and falling on the floor. [15:19] s/axles/axle/ [15:19] makes sense [15:19] Having it upside down puts the burrs at "zero", as Doug calls it. [15:20] k [15:20] so you loosen it and spin the axle to get minimal bob [15:20] So when the inner burr is off center, one of the "far" points of the oval is scraping the outer burr, without being balanced by the other "far" point of he oval. [15:22] Keep in mind that the outer burr doesn't have straight walls. [15:22] It's a cone. [15:22] right [15:22] *** chmod\ has quit IRC (Ping timeout: 246 seconds) [15:23] So as the far point of the inner burr comes into contact with the outer burr, it wants to try and push into it. [15:23] But since it's a cone, to the inner burr, it looks like a ramp. [15:24] So the inner burr basically creeps up the "ramp", bringing the entire shaft assembly with it. [15:24] so shift the outer burr to minimize "ramp" [15:24] It's basically the way that the far point of the inner burr pushes through the wall of the outer burr. [15:25] It seeks the path of least resistence, and that means creeping up along hte wall of the cone, where the diameter of ther outer burr is larger. [15:25] Well the ramp is always there, you just want the far ends of the oval to be balanced against one another. [15:26] up_the_irons: you around? [15:28] qbit: It might be easier to visualize if you take out the burrs and hold them relative to one another in space. [15:30] think i have a pretty good visualization [15:34] *** chmod\ has joined #arpnetworks [15:38] *** Ehtyar has joined #arpnetworks [15:43] Actually, let me revise that. [15:43] I just found my notes. [15:43] I was describing to you an earlier version of my theory. [15:43] There doesn't have to be any balancing. [15:44] In fact, the inner burr doesn't have to be an oval. [15:44] It could be (and probably is) an ellipse. [15:44] Where one of the far points never touches the outer burr. [15:45] As far as our model is concerned, the inner burr can be modeled as just a single stick protruding perpendicularly from the shaft. [15:46] If you imagine the stick to be a piece of chalk, then it draws its path on the surface of the outer burr. [15:47] k [15:47] When it's perfectly centered, the path is a level circle. [15:47] right [15:47] When it's off center, the path it traces is an ellipse. [15:47] It climbs higher along the cone, then drops down to a lower point. [15:48] http://csep10.phys.utk.edu/astr161/lect/history/conic.gif [15:48] Compare circle and ellipse in that diagram. [15:48] The cone is the outer burr, of course. [15:49] aye [15:49] The motion of climbing higher on the wall of the cone and then dropping down again is what causes the bobbing motion of the axle. [15:50] yep [15:50] When it's centered, the path is a level circle that has a constant height along the cone, so there is no bobbing. [15:52] yerp [15:53] If you do as Doug says, and leave the three long bolts loose, and just rotate the handle, then it self-aligns. [15:53] that's how i did it last time [15:53] tightened ~ to his spec.. [15:53] but it's wobbled loose [15:53] Since the outer burr is free to move around, the inner burr just sort of pushes the outer burr into place, since that's easier than climbing the wall and moving the entire shaft up along with it. [15:54] Well you probably want to tighten it more. [15:54] But the problem when you do that is that overtightening actually puts it out of alignment. [15:55] And I think that's why he tells people not to overtighten. [15:55] Now, we have to investigate *why* overtighening puts it out of alignment. [15:56] because the middle plate moves the outer burr [15:56] * moves it's angle [15:56] Yeah, sort of. [15:57] The appartatus isn't a perfectly rigid structure. [15:57] As you tighten, things bend slightly. [15:57] Enough to put it out of alignment. [15:58] *** chmod\ has quit IRC (Ping timeout: 246 seconds) [15:59] k [15:59] But if you only tighten one bolt at a time, and check the alignment before you do anything else, then you *know* for sure how it was distorted. [16:01] And fortunately, he only used three bolts, which makes this process easier. [16:01] If he had use four, then it would not only be a longer process, but more complicated. [16:02] So when you tighten a bolt, it pushes the steel plates closer to one another on that side. [16:02] It has the effect of tilting that side of the outer burr towards the handle. [16:03] which may or may not be a good thing.. depending on the ellipsieness [16:03] Well, as far as alignment goes, what effect does tilting the burr have? And how could you correct it? [16:06] *** chmod\ has joined #arpnetworks [16:07] seems if you loosen the bolt by the "ramp" and tighten the others .. it should reduce the ramping [16:07] Yes, but then you have one bolt loose. [16:07] right - but i don't mean all the way [16:08] And how do you know that tightening the other two bolts won't put it out of alignment in another direction? [16:08] by respinning [16:08] But that won't work once it's torqued down. [16:09] That's the whole point of overtightening - so that *won't* happen. [16:09] Otherwise you'll be realigning every week. [16:10] Tightening a bolt has the effect of lifting the side of the outer burr that the bolt is on upwards, towards the handle. [16:10] As far as the "ramp" goes, it's the same as moving the outer burr closer to the inner burr. [16:11] Since the ramp is being lifted, the "stick" representing the inner burr is now touching a lower part of the cone. [16:12] Actually hold on, let me visualize this to make sure I have the direction right. [16:12] Maybe I should draw a picture. [16:13] *** chmod\ has quit IRC (Ping timeout: 246 seconds) [16:14] heh [16:14] right on [16:18] *** chmod\ has joined #arpnetworks [16:53] Hmm, I have to go make dinner. [16:53] Anyway, just tap the burr on the opposite side of where you tightened the bolt. [16:54] Since tightening that bolt reduced the clearance, shifting the outer burr in the direction of that particular bolt will increase the clearance. [16:55] And just do that for each of the bolts. (You'll have to tap harder as you progress through the bolts.) [16:56] It's possible to tap it too much, and it's tricky to tell when you've done so. [16:56] But since the configuration of the three bolts is a triangle, pushing the outer burr too far when you're tighening one of the bolts is the same as putting it out of alignment with respective to the two other bolts. [16:57] And you can correct for that when you visit the two other bolts. [16:57] qbit: ^ [17:10] rad [17:10] thanks :D [17:11] have a good dinner! [17:18] up_the_irons: you there? [17:18] Webhostbudd: yes, but busy [17:18] oh [17:18] alright [17:18] quick questions, no problem; need me to do something, gotta wait :) [17:19] I'll just submit a ticket then [17:20] roger [17:36] Channel poll: raw backup space (rsync) to be available for $0.20 per GB, good price? A bit cheaper than Linode and 30% cheaper than RootBSD [17:36] hmmm [17:36] that sounds pretty good [17:36] $0.20 per GB per month? [17:36] yeah [17:36] yea [17:36] i like that [17:37] so if you had a small plan ($10) with 5GB disk, you'd pay only $1 more for enough space to fully rsync all that [17:37] but im guessing you can rsync just individual files too [17:37] no one is going to sync their entire fs.... [17:37] at least, i would hope not [17:37] yes, that's the idea, you run rsync within your vps [17:39] i think i'd build that backup host with FreeBSD + ZFS mirror. Initially with just a 2 disk mirror to get it off the ground. I already have a blade ready for it.. [17:39] chroot home dirs, like ryk suggested [17:42] yea [17:42] definitely [17:52] up_the_irons: you have a blade server? [17:52] thought you use supermicro twins [17:53] or super twins or whatever they're called now [18:02] ryk: i do have a blade server, not the twins [18:03] food time [18:03] * up_the_irons grabs grub [18:04] lol [18:07] up_the_irons: I'd be up for it. [18:25] hot [18:32] up_the_irons: raidz probably makes more sense? [18:32] up_the_irons: i wonder if it's possible to do some kind of lvm snapshot copy type backup... [18:32] which you could "recover" from if you wanted to [18:34] the problem with mirror is that if you want to grow it you'd have to add two more disks, or add a raidz on .. as zfs doesn't allow changing from mirror to raidz [18:37] raidz would not be a good choice for this, imo [18:37] 1) it's backup [18:37] 2) raidz is not easily expandable [18:37] now, you can keep adding raidz devices to your zpool, but you have to add an entire raidset every time you want to expand it. [18:38] mirroed you have to add a pair each time [18:38] raidz you have to add 3 disks every time [18:38] err 3 or more [18:38] and of course you're going to want to do more, because eww 3-disk raidz? [18:38] so that gets expensive. [18:38] what's wrong with 3 disk raidz? [18:38] *** jbum has quit IRC (Quit: jbum) [18:38] what's wrong with a mirror vdev? [18:39] 3 disk raidz gives you twice as much storage space as mirror [18:39] it also gives you faster write speeds [18:39] but if you know up_the_irons , you know he's a raid 1- guy [18:39] *10 [18:39] it's a bit different for backup space to virtual machine storage [18:40] there's no requirement for speed, here. i'ts backup space. [18:40] well yaeh, most of the time there isn't [18:41] but if lots of people cron at the same time their backup.. [18:41] and someone tries do a read at the same time [18:41] or noties their backup taking ages [18:41] raidz gives higher write bandwidth [18:41] i mean, you're right -- if it had to be parity raid, i would choose raidz over raid5 [18:41] *** HighJinx has quit IRC (Quit: Computer has gone to sleep.) [18:42] but yeah, even for normal performance generally speaking, i'd say that 4 raidz3 set's stripped would be competitive with raid10 with 12 disks [18:43] raidz3? or 3-disk raidz? [18:43] although when getting to 12 disks the chances of dual disk failure increases [18:43] i thought raidz3 was super-redundant [18:43] 3 disk raidz [18:43] sorry, confusing terms a little :) [18:43] i don't think there's a raidz3 [18:43] there's raidz2 [18:43] there is, now, it's new-ish [18:44] generally speakign above that i think people say you should have more than one data set or more than one raid volume [18:44] err more than one pool [18:44] i'm confusing terms again [18:46] anyone the rational was if you have 3 2tb hard-disks with raidz you get 4 tb of disk space, if you have 4 2tb hard-disks with 2 pairs of mirrored drives you get 4tb of disk space [18:47] with 6 disks.. raid-z gives 8 tb .. raid mirrored gives 6 tb [18:47] i suppose it's not a big diff [18:48] it'd be better if you could grow storage nicely [18:49] like just chuck another 2tb in and rebalance [18:51] so, having never used raidz, i haven't measured write speeds. you're saying write is faster? [18:51] because that's contrary to conventional wisdom i would associate with parity raid [18:52] read is usually faster, write is slower due to the calculations [18:52] calculations are minimal [18:52] bsaically it can write half the data to one disk half to the other [18:52] as well as the parity [18:53] so if you write 100 gig of data [18:53] you write 50 gig to 3 disks [18:53] whereas with mirrored raid you write 100 gig to 2 disks [18:53] an thus you write 150 gig versus 200 gig [18:53] and read? [18:53] read performance is similar for sequential [18:54] the problem with raidz is for lots of small reads [18:54] you reduce your seek performance, because say you have 128k stripe size per disk [18:54] then you'd have to read 128k off each disk [18:54] for even a 4k read [18:54] limiting seeks to that of a single disk [18:54] with backups though they're by far sequential [18:55] so it can just read huge chunks off each hard-disk [18:55] or write big chunks to each hard-disk [18:56] but y eah when people say about the overheads of raid parity calculations it's way less significant than aes (https, ssh, etc) [18:56] sure it may have been a significant overhead in 486 days [18:56] or more so in sparc days [18:56] err early sparc days [18:56] but it's not a significant concern. [18:57] aes is more likely to be a concern [18:57] if lots of people scp/ssh at once [18:57] but even then if you have multiple cores without hardware acceleration it should be fine anyway [19:01] also another thing to keep in mind with raid10 versus basically raid 50 is that most work loads cache the majority of their reads [19:01] but you can't really cache writes, you can buffer them... [19:01] but sooner or later you have to write them to the disk [19:01] whereas reads just can from memory a lot of the time [19:02] so for things like hosting web sites, it's mostly a "write load" not a "read load" [19:02] because of appending the log file with updated accesses etc [19:02] although it's also mostly small writes [19:03] but if you can't keep your most visited documents in memory, and are frequently going to disk, then either you're starved for memory, or you have a huge dataset [19:04] and if you have a huge dataset and it's text files, it may make more sense to compress your memory cache [19:04] apache traffic server is an example of a proxy server that can compress it's memory cache [19:04] i don't know why it's not used more often, it's faster than varnish or squid or ngnix [19:04] ngnix [19:05] *** warex has quit IRC (Ping timeout: 245 seconds) [19:10] apache traffic server? [19:10] * ryk googles [19:11] it was a yahoo project that went open source and was made part of apache's greater uhh [19:11] whatever it's called [19:12] it's multithreaded, high performance, under active development [19:42] up_the_irons: Another thing that might be nice is a domain for customers. [19:43] You know, for those of us who don't care to get our own. [19:44] Those free dns services are a little annoying because you have to update the ip evey once in awhile, even with a static ip, or else they drop you for inactivity. [19:48] qbit: I'm investigating another possible reason for why tightening the bolts puts the burr out of alignment. [19:48] *** HighJinx has joined #arpnetworks [19:49] qbit: It has to do with the type of nuts that are on the end, and how they grab the bottom plate as they're tightened. [19:51] If the long bolt is not perfectly straight through each plate, tightening the nut will straighten it. [19:52] But if the teeth in the nut have grabbed into the plate, then the position of the plate will shift with the nut. [19:55] I'm going to see if adding a washer will change anything. [19:56] But it'll have to wait until tomorrow. [20:14] right on [20:15] seems that if you gighten from the top - and keep the bottom in one position it owuld hav ethe sameish effect [20:16] Maybe, but it still wanders a bit. [20:17] btw, I got rid of those four smaller screws holding thd outer burr. [20:17] And the springs, too. [20:18] interesting [20:18] whY? [20:19] cpu hs mounts? [20:24] Because I think they just get in the way if you're planning on overtightening. [20:25] They certainly don't add anything. [20:26] true [20:26] HighJinx: Coffee grinder. [20:26] ahh [20:27] If you're going to tighten to the point that the springs bottom out, then there's no reason to have them. [20:28] And the only reason the four small bolts are there is to keep the spring in place. [21:03] has anyone had success with virtio on kvm? [21:03] errr [21:03] freebsd virtio modules on kvm [21:33] I have been working on some web based DNS tools, if anyone would care to provide some constructive criticism: http://dns.winvive.com [21:41] mnathani: pretty array formatting :) [21:41] lol gotta love print_r ;) [21:42] :-) staticsafe [21:42] I like it tbh, simple and clean [21:43] Odd... according to your site, mnathani, google.com isn't DNSSEC. That doesn't seem right [21:43] webhost: i've had openbsd work with virtio on kvm [21:43] I modeled some of the tools after http://www.dnsstuff.com/ [21:43] but openbsd takes code from netbsd not freebsd [21:44] mnathani: +1 for ipv6 [21:44] Thanks brycec [21:44] dont think google.com is dnssec yet [21:44] winvive.com is however [21:45] damn, really need to read up on dnssec [21:45] touche, google.com really isn't signed [21:46] You just figure... IT'S GOOGLE [21:47] * brycec just found https://chrome.google.com/webstore/detail/dnssec-validator/hpmbmjbcmglolhjdcbicfdhmgmcoeknm too, for those who care [21:48] ah indeed you are mnathani http://dnssec-debugger.verisignlabs.com/winvive.com [21:49] * brycec should get around to figuring out what's needed in signing his domains [21:49] I have a bunch of tools like that over at my dnssec signed blog: http://mnathani.com/blog/dnssec-links/ [21:49] *links to tools rather [21:55] What, using your own IP is too hard? Not knocking the idea really, just curious at the gap between "I can't be arsed to get a domain for $1.10/yr" and "I can't be arsed to type an IP address or edit my hosts file" [19:42:48] up_the_irons: Another thing that might be nice is a domain for customers. [21:56] up_the_irons: The rsync backup space is a neat idea. Critical question time - why would I use that space over Amazon's S3 RRS which is $.09/GB/mo? Besides saving on VPS b/w costs. [21:56] * brycec already uses S3 RRS for backups now, every single server I admin, total about $16/mo [21:59] Aaaand before I'm over this dnssec kick - hey up_the_irons why isn't arpnetworks.com DNSSEC signed? :) [21:59] here is another question, why are the arpnetworks customer resolvers not validating DNSSEC? [22:59] Domain names are easier to remember than ip addresses. [23:02] < CaZe> up_the_irons: Another thing that might be nice is a domain for customers. <-- you mean like the dns records for "your-name.cust.arpnetworks.com" that are created when you sign up? [23:11] Ah, I didn't know about that. [23:13] But it'd be nice if we could change the name. [23:16] That's what name.com is for. [23:30] *** _mnathani_ has quit IRC (Ping timeout: 240 seconds) [23:32] *** mnathani has quit IRC (Ping timeout: 255 seconds) [23:43] *** _mnathani_ has joined #arpnetworks [23:43] *** mnathani has joined #arpnetworks