BitFolk Users

users@mailman.bitfolk.com

1117 discussions

by Mike Zanker

I've set up IPv6 tunnelling between my VPS and a linux box at home (both CentOS) and now have IPv6 working on my home network a treat. The problem is, though, that the tunnel appears to time out after a few minutes when traffic stops flowing and I start getting "network unreachable" errors when trying to connect out from my home network. If I ping6 something on the home network from the VPS it appears to wake the tunnel up again. Is there a way round this (other than having a cron job ping something every minute or so) - maybe some sort of timeout parameter when setting up a sit tunnel? Thanks in advance, Mike

12 years, 5 months

IPv6 VPN with tinc

by Stuart Swindells

I tried following the guide at https://tools.bitfolk.com/wiki/IPv6/VPNs to set up a tunnel between my VPS and a machine at home (both running Debian testing), the plan being to give out v6 addresses to the machines at home. I have a /56 assigned to my VPS (2001:ba8:1f1:a00/56), and the VPS's eth0 has 2001:ba8:1f1:a00::2 assigned to it as well as an IP from the original /64 (2001:ba8:1f1:f07a::2). The IPv6 on there seems to work fine (I can ping ipv6.google.com etc.). The two ends are assigned IPs in 2001:ba8:1f1:a01::/64 - the VPS has ::1, the machine at the other end ::2. When I start tinc on both machines, I can ping the other endpoint IPs (i.e. ::2 from the VPS, ::1 from the machine at home) as well as the VPS's other IPs (i.e. I can ping the IP from the original /64 from home), but the machine at home can't get to anything beyond the VPS. On the VPS (ra): tinc.conf Name = ra ConnectTo = camulus Interface = camulus Device = /dev/net/tun DeviceType = tap BindToAddress = 85.119.82.221 Port = 655 Mode = switch tinc-up #!/bin/sh ip address add 2001:ba8:1f1:a01::1/64 dev $INTERFACE ip link set dev $INTERFACE promisc on ip link set dev $INTERFACE up exit 0 On camulus: Name = camulus ConnectTo = ra Interface = ra Device = /dev/net/tun DeviceType = tap BindToAddress = 192.168.1.13 Port = 655 Mode = switch tinc-up #!/bin/sh ip -6 addr add 2001:ba8:1f1:a01::2/64 dev $INTERFACE ip link set dev $INTERFACE promisc on ip link set dev $INTERFACE up ip -6 route add default via 2001:ba8:1f1:a01::1 dev $INTERFACE exit 0 On both: hosts/camulus Port 655 -----BEGIN RSA PUBLIC KEY----- -----END RSA PUBLIC KEY----- hosts/ra Address = 85.119.82.221 Port = 655 -----BEGIN RSA PUBLIC KEY----- -----END RSA PUBLIC KEY----- What am I missing? Cheers, Stuart

12 years, 5 months

Bitfolk SpamAssassin / SPF

by Nigel Rantor

So, I receive mail that would be killed by SPF checks and I'm thinking of getting my exim server to use SPF because of this. So, to the VPS users, I was wondering if anyone who has implemented SPF checks found downsides to it? And to the Bitfolk admins, have you considered adding SPF checks to the Bitfolk SA? n

12 years, 5 months

Proving that you are you

by Andy Smith

Hello, Today a customer popped up on IRC saying that they had broken their VPS and couldn't remember their account details in order to use the console / rescue VM. Unfortunately they had also at some point in the past disabled email password reset, so they were unable to regain access. My concern at that point was that since they had previously disabled email password reset they were obviously security-conscious, so I did not feel comfortable resetting their password and giving it out to them over IRC. Of course, I could see that the customer's service was down as claimed, which did lend weight to the story and meant that I could not just ignore the issue. In the end I asked the person on IRC to send me a photo or scan of a utility bill bearing their name and address as present in BitFolk's customer database, and on receipt of that I did reset their password. If it had been you in the customer's position would you have considered that reasonable? If you have disabled email password reset, are you comfortable with this being circumvented by someone who is able to present a convincing image of a utility bill to support(a)bitfolk.com? Perhaps you can offer some guidelines for how this should be dealt with in future so that there can be a consistent response. Suggestions revolving around the customer identifying themselves using public key crypto (PGP keys, SSH keys) are fine but do bear in mind that most customers have not presented either a PGP nor SSH key to me, and that would have to be done before it was actually needed. I could require that an SSH and/or PGP key be uploaded to the panel before the panel allows you to disable email password resets, though there would still need to be a plan in place for the inevitable case where the customer claims to no longer have access to any of the keys they have uploaded. Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting

12 years, 5 months

Re: [bitfolk] users Digest, Vol 45, Issue 2

by Steven Walker

Could you ask them to add a simple message to their home directory via ssh thus proving they have access to the account? Google do something similar, asking customers to add a randomly generated subdomain to the dns records. Steve

12 years, 5 months

vps ping response times

by Joseph Heenan

Hi all, I got into a discussion with one of the people I'd recommended to bitfolk about ping times to VPSes (he was seeing some spikes). So I setup some graphs, but didn't see what I expected. Here's the graph for his vps: http://f8lure.mouselike.org/archived_graphs/baa.muuh.co.uk_day25.png which basically looks fine (which doesn't match what he was seeing from his own graphing, which is odd), and here's the graph for my VPS: http://f8lure.mouselike.org/archived_graphs/button.heenan.me.uk_day25.png The number of huge spikes (and some packet loss, shown red) on this surprised me. Would this kind of result be expected? Both graphs are for yesterday afternoon. Both vpses where pretty much idle as best we can tell. Cheers, Joseph

12 years, 6 months

At-risk notification for 2012-06-30 1100-2100Z

by Andy Smith

Hi, TL;DR version: There's some work being done on our provider's network on Saturday 30th June between the stated times. It shouldn't be noticeable. Longer version: On Saturday 30th June between 1100Z and 2100Z our colo provider will be undertaking some upgrade work on its core network. This work is not expected to have any impact on your BitFolk service. Most of the work will be taking place in racks not directly relating to BitFolk. At some point during the maintenance window one of the switches to which several BitFolk nodes are connected will be replaced with an upgraded model. All BitFolk nodes are connected to two separate switches and interface bonding should ensure that no interruption to service is experienced. These nodes are: curacao faustino kahlua obstler president urquell I will be online while the work is being carried out just in case anything does go wrong. Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting _______________________________________________ announce mailing list announce(a)lists.bitfolk.com https://lists.bitfolk.com/mailman/listinfo/announce

12 years, 6 months

IPv6 connectivity was broken between about 2105Z and 2120Z on some servers

by Andy Smith

Hi, Between approximately 2105Z and 2120Z tonight there was a total loss of IPv6 connectivity for customers on the following servers: cosmo dunkel kahlua obstler urquell This was because our transit provider did some (planned) maintenance involving switching off a router, and the above servers were not correctly set up to have a redundant IPv6 default gateway. Connectivity was restored when alerts were received and a working IPv6 default gateway was configured. It appears that the incorrect settings were used when the above servers were switched over to use interface bonding two weeks ago, to provide layer 2 resilience. Unaffected: barbar bellini curacao faustino kwak The correct redundant IPv6 gateway is now configured on all servers. Please accept my apologies for this error, and the resulting disruption it may have caused you. Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting _______________________________________________ announce mailing list announce(a)lists.bitfolk.com https://lists.bitfolk.com/mailman/listinfo/announce

12 years, 6 months

Network issue, starting around 1819Z today

by Andy Smith

Hi, As of aprox 1819Z there have been network problems at our colo/transit provider, resulting in high packet loss. This is not specific to Bitfolk; it affects all customers that I am aware of. I've spoken to provider and they are working on it, is more info as I have it. Apologies for the disruption. Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting _______________________________________________ announce mailing list announce(a)lists.bitfolk.com https://lists.bitfolk.com/mailman/listinfo/announce

12 years, 6 months

Xen Security Advisory CVE-2012-0217 - 64-bit PV guest privilege escalation vulnerability

by Andy Smith

Hi, As you may be aware from: http://seclists.org/oss-sec/2012/q2/500 there is a rather serious Intel CPU bug which can allow 64-bit paravirtualized guests to crash and/or potentially gain control of the entire node. TL;DR version: BitFolk is not affected. You don't need to do anything. Longer version: As luck would have it, BitFolk does not happen to support 64-bit guests, so the vast majority of customer systems cannot make use of this exploit. There is no technical barrier to prevent customers installing their own 64-bit OS, however, and two customers have done so. In the very short term, with the exception of the two customers who are already running 64-bit, I have prevented 64-bit guests from being booted. I shall contact the two customers individually to arrange for them to be moved to an upgraded node. The alternative would be to upgrade and reboot every node. For some nodes this would mean a full OS upgrade. This will be done eventually but over a longer time span, as it will obviously be necessary in order to support 64-bit guests. Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting _______________________________________________ announce mailing list announce(a)lists.bitfolk.com https://lists.bitfolk.com/mailman/listinfo/announce

12 years, 6 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

BitFolk Users