I have no way to describe this article properly: http://www.cnn.com/2011/12/01/us/tennessee-crashes
That's a large number of cars.
up_the_irons: Can you set up extra-small VPS's?  I'm thinking 64MB/1GBish...
raptelan: yeah but the price isn't going to fall below $10 ;)
so u might as well get the $10 one
up_the_irons: ah, bummer. :P
I was hoping I could get a couple for $10, to have some "redundant" dns servers
speaking of which, I know you've just got the one location, but can you locate VPS's on physically separate hardware upon request?
yeah, and i typically do by default
not nice to put all customer's eggs in one basket ;)
up_the_irons: I'll probably add a second $30 one then
set up DRBD between the two
up_the_irons: what's the proper way to add a service to existing account?
raptelan: use regular order form and put in same email as on existing account
raptelan: specify which IP you want assigned to the new vps in additional comments; if u have no free IPs, you have to order a bigger block
i used DRBD once
it is pretty brutal to the kernel (will crash a whole box if you make a mistake).  i didn't like that about it
two of the three kvr03 outages i had many moons ago was due to drbd.  so i stopped using it
really?
I used it for years on a couple dozen machines quite happily.
cool, works for you then :)
well I've never tried it on VPS's :/
speaking of which
i didn't do it on VMs either, it was on the host boxes
up_the_irons: if I order up a second VPS, can I get a virtual private network between them (with secondary ethernet interfaces)?
and by virtual private network, I don't mean VPN :P
heh
just a couple interfaces that I can assign addresses like 172.16.0.1/2 and have them talk to one another isolated from other traffic
raptelan: VMs belonging to the same account already are on the same private vlan.  i can give you more interfaces too, but they'll still be on the same vlan
up_the_irons: well, my thought is that if I'm listening to traffic on one interface I don't want to hear the other one.
up_the_irons: what is the likelyhood if raptelan sets up vlans on his 'virtual' nics that the vlan tagged packets would arrive at his other virtual nics unscathed?
raptelan: that may not be possible; internally (on the host), multiple VM interfaces belong to the same bridge, which is the bridge for the customer's vlan.
toddf: good question
raptelan: you might consider setting up a gif(4) interface if vlan(4)'s are out of the question. or gre(4). at some point just setup ip aliases and be done with it.
I'm not familiar with those
raptelan: you may wish to consider that the only systems seeing the traffic other than the switches are your vm's and arpnetworks' routers
think I've heard of gre somewhere before
raptelan: try 'man gif' or 'man gre' .. presuming you're on a bsd system
toddf: I'm not concerned about privacy of the data, I'd just like to have what appears to be physically separate interfaces from the hosts
toddf: nah, linux
then you want sit(4) and gre(4) if there is such thing as man pages or documentation for linux *zzzzing!*
haha
toddf: the mtu on the VM interfaces is 1500, or at least reportedly 1500 (linux networking details are not always honest), so vlan tagged packets shouldn't work.  but i can try to raise the mtu and see what happens
if I could do something like drbd on netbsd, then I'd probably give that a try
up_the_irons: it would be more interesting to see if vlan tagged packets work if they're not full frame size, i.e. ping packets etc. its a question if your switches filter them out to other vlans or if they keep them encapsulated inside the vlan they were transmitted in
if randalshwartz were kicking at the moment he could setup at test easily I presume between two of his many vm's ;-)
toddf: yeah, not sure if that would work or not :)  I don't believe the Cisco would strip it if less than mtu
some switches isolate vlans to the point that they don't permit tagged vlan packets inside. or they'll inject those packets into the corresponding vlans already defined within the switch with no way to have the transmitting host receive a reply.
:/
it would certainly be a win if it did not molest them, but until verified I surely wouldn't count on it
yeah, cisco won't do that type of injection
I don't want to set up my own vlan or anything else
I just want to assign private IP addresses and be able to talk to each other
I am sure raptelan could shrink the mtu of his vlan(4) interfaces sufficient to avoid hitting the 1500mtu ceiling of the parent interfaces
raptelan then just do eth0:1 and be done with it
toddf: yuck. :P
dealt w godaddy.com again. ugh
raptelan: thats what we're telling you. all roads lead to the equivalent of that _or_ you tunnel between the hosts somehow (vlan or gre or sit)
that may not be necessary, i just checked on one of my VMs that *does* received tagged packets, and dumb linux says the mtu is 1500, even though full size tagged packets are making it through.  therefore, the mtu on certain interface types (like tap) in linux, just must not care
raptelan: you as a customer of arpnetworks get one vlan for your playing pleasure between your hosts. maybe with enough green stuf you could convince up_the_irons you need a 2nd private internal vlan but thats between him and you. I suspect its technically possible just wasteful of his 4096 vlan limit.
"equivalent of that" that that meant eth0/eth1 would be nice :)
well "need" is a strong word, I don't need it.
raptelan: 'equivalent of that' up_the_irons offered you eth0 and eth1 on your vms, but with the understanding they're all plugged into the same ethernet segment on your personal vlan
2nd private vlan is _possible_ but just not worth the overhead and "one off" design.  i have never assigned more than one vlan per customer and i don't want to start now :)
and at that point, whats the point? eth0 & eth1 or eth0 & eth0:1 ? same difference to me
toddf: yeah that should be just fine I imagine.
toddf: yes, exactly
toddf: raptelan : yeah, i've given multiple physical NICs to VMs for the purpose of easier pf rule making on the customer end, but beyond that, the traffic is not segmented in any way
toddf: well with modern tools you don't use eth0:1 anyways, you just assign multiple addresses to eth0.
but I want to simulate actual hardware to some extent
raptelan: you can tell how long its been since I've actively admin'ed linux ;-)
raptelan: yeah, but sometimes having a separate interface _name_ can help with, for example, firewall rules
up_the_irons: indeed, which is why I'd love an eth1 ;)
raptelan: sure, you can have an eth1, just put it in the order comments
plus then if I'm going all crazy setting up firewall on eth0, I can still get back in via eth1 :D
hah right
up_the_irons: order placed :D
cool :)
man i got a lot to do tonight...   put in new box last night, so i can set it up tonight, then billing, then orders, then support.  u guys keep me busy
hopefully that's in a good way
mine's not urgent if you need to put something off
raptelan: up_the_irons is typically very methodical. order of orders tends to rule.
raptelan: being busy is better than being bored ;)
I tend to aggree
time for sleeps, good night all
'night
up_the_irons alive mate?