Hi,
Google are shutting down their Checkout payment platform as of 20th
November 2013, so BitFolk will stop accepting payments that way
around 12th November.
As you may be aware if you are following the other list¹, credit card
payments are now available.
I suggest that refugees from Google Checkout pay by this means in
future, and it would be great if everyone else paying by anything
other than Direct Debit would consider it also.
The initial implementation requires you to input card details every
time and I do understand that is a major usability downside, so we
will improve that as soon as we can to have storage and continuous
authority as *options*.
The credit card payments are going through https://stripe.com/ with
the card details being passed between your browser and Stripe using
JavaScript. All BitFolk gets is a unique token that we use with
Stripe to kick off the payment, so we're not seeing or storing your
card details at any point.
Here's some more info about payment methods that are supported:
https://tools.bitfolk.com/wiki/Payment_methods
Cheers,
Andy
¹ http://lists.bitfolk.com/lurker/message/20131021.081408.6fc996c8.en.html
--
http://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
Hi All,
I just noticed (and was perturbed by) the fact that, under Debian 7, the number of failures since last login is unavailable at the login.
The default under Debian 5.0 seems to have been set to report the number of failures since last login (if there were any).
Something has changed in the login procedure since Debian 5.0
The contents of /etc/login.defs seem identical from 5.0 to 7, and I am perplexed because I would like to restore the behaviour at login of Debian 5.0
Any/all suggestions are welcome, as usual.
Cheers
Hi,
A while ago a customer who successfully installed Gentoo on their
VPS emailed me a guide on how they did it. I hastily pasted it into
a wiki article with light reformatting, resulting in this:
https://tools.bitfolk.com/wiki/Installing_Gentoo
Earlier I had a go at following it but unfortunately I failed pretty
much immediately, so in my opinion it could do with some work.
I possibly could work out where I went wrong by reading the Gentoo
handbook, but if I cannot follow the guide then I don't think that
someone with less Linux experience than me can follow the guide
either, thus making the guide not very useful.
Also I don't have a lot of personal interest in researching how to
install Gentoo. :-)
Rather than solely hassling the person who originally contributed: I
know there are some Gentoo fans out there, so if you feel you could
improve the guide in any way please do so by editing it. All
customers can edit the wiki by logging in with their usual BitFolk
credentials.
Other guides I have successfully followed in the past despite having
very little interest in or knowledge of the finished product include:
https://tools.bitfolk.com/wiki/Installing_Arch_Linuxhttps://tools.bitfolk.com/wiki/Installing_Slackware
so that'd be the sort of level to aim for - not that those can't be
improved too! :)
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
> The optimum programming team size is 1.
Has Jurassic Park taught us nothing? — pfilandr
Hi All,
this is just a heads-up notice.
Recently, I have been stalked by a user at ovh.net . They seem to be well-financed and persistent.
I was surprised to find that, by default, the log file /var/log/sulog is disabled Debian 5.0 and Debian 7.
This behaviour is dis/activated in /etc/login.defs
su log files are handy to check for intruders, and I am surprised that Debian (and possibly others) have not seen fit to enable a default /var/log/sulog
Of course, most of you already know this, but this note was designed in case one of you was heretofore unaware.
Cheers
Hi,
Previously it was noted that kernels compressed with XZ are not
supported:
http://lists.bitfolk.com/lurker/message/20130523.110244.f70b2d77.en.html
As far as I am ware this only affected people trying to run Debian
jessie (testing) since that was the only distribution I know of that
switched to XZ for kernel compression.
I have now added support for XZ compression and it has been tested a
little by myself and a few other customers, so it should now be
working. If you are doing a dist-upgrade from wheezy then it may
still be wise to keep the wheezy kernel around in case of problems.
Also Debian jessie seems to work now as a net install; previously it
was missing a netboot Xen installer and the XZ kernel support also.
Please bear in mind that Debian jessie is an unreleased testing
branch and may break at any time for reasons beyond our control. I
would be interested to know if it is broken at any time, but can't
promise speedy fix.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
Hi All,
I just discovered an unwanted sendmail listener at 63.141.225.90 on my bitfolk vps machine by doing a
% ps aux
I still don't know how I was compromised.
At any rate, it seems my sendmail config file is deficient.
I've grepped through the /etc directory for the offensive address to no avail.
When my email client opens, it tells me "Folder is open by another process, access is read-only".
This concerns me, because there are no visible other processes.
This is what caused me to look at 'ps aux', and discover the unwanted listener.
I believe this situation can be fixed, only I know not how.
Any advice will be gratefully received.
Cheers
I have just done an upgrade of Debian Squeeze to Wheezy on my VPS using
the net install option. Everything seems to have gone well (cross
everything, touch wood etc). Before doing the reinstall I read all the wiki
articles and so on. I don't know much about kernels, but all the wiki notes
talk about using the -bigmem flavour, though the installer installed -pae
flavour. Everything seems to be working OK. Have I just been reading old
instructions? Or should I be looking to install a different one?
Keith
--
Keith Williams
Keith's Place www.keiths-place.co.uk
Tailor Made English www.tmenglish.org
West Norfolk RSPCA www.westnorfolkrspca.org.uk
My site (ilovephilosophy.com) was down this morning, and I suspect that my
registrar has fouled something up. I suspect this because nothing is wrong
in Nagios, the site loads normally using the IP, and today was the day my
registration would have expired had I not paid to renew it last week...
Running tracert returns "Unable to resolve target system name
ilovephilosophy.com"
Running nslookup returns "*** UnKnown can't find ilovephilosophy.com:
Non-existent domain"
Is there anything else I can do to test my suspicion, or does any of this
confirm it? I know it isn't just me or my network, because my users around
the world are reporting the same trouble. I've as yet been unable to reach
anyone at my registrar, and in the meantime I'm hoping to rule out any
other possibilities.
Thanks,
Mike
Hi,
If you currently pay by Direct Debit authorization then you are
probably aware that we use GoCardless for this. If you don't then
the rest of this email is probably not of interest to you.
The way it works right now is that you create an account with
GoCardless by giving them your bank details, and that sets up a
Direct Debit instruction between your bank and them. Then, you
authorize BitFolk's payment plan which asks GoCardless to allow up
to a certain amount during a certain time period. GoCardless
enforces the limits of that plan.
That works fine, but the problem comes when you order an upgrade
that makes your plan more expensive. At the moment we need to cancel
your payment plan and ask you to authorize a new one. It's not a big
deal but it is perhaps not the best user experience. When you pay
other companies by Direct Debit they get to take whatever they want,
so you're not asked to re-authorize when, for example, your council
tax or gas bill goes up.
GoCardless have had a feature request open for a long time that asks
them to implement a way for users to authorize a new limit (or
perhaps for the customer to indicate that they're not bothered).
They have now closed this request and advise that if merchants want
to charge varying amounts then the merchant should ask the customer
to authorize a limit that is higher than any payment that would ever
be normally requested, e.g. £5,000 per month.
The question that immediately sprung to mind here was, "isn't my
customer going to be a bit disturbed by being asked to authorize a
payment plan that allows up to £5k to be taken out of their bank
account?"
Their answer to this was to add an option so that payment plans
don't have visible (to the customer) limits any more.
As I say, that is generally how Direct Debits work: you authorize
the instruction and you're trusting the organisation to only take
when they are actually owed. If they screw up and take too much, you
can dispute it with your bank and it immediately gets reversed.
There isn't normally a middle man verifying payment requests.
If this was how GoCardless had worked from the beginning then I
wouldn't have an issue, but the fact is that everyone currently with
a Direct Debit authorization to BitFolk knows they have a limit on
it that (barring GoCardless making a mistake) only allows the exact
amount to be taken.
Would you have a problem with that limit being removed? I'd be
interested to get feedback from those currently using Direct Debit
to pay. Feel free to let me know off-list if you prefer.
It's been nearly a year of using GoCardless and there haven't been
any issues of taking too much money. I would be comfortable with
setting all future authorizations to have no limit on them, as I
think the improvement to user experience of just being able to order
an upgrade is worth it. If there is a massive outcry I won't do it
though. I may also consider making it an option (defaulting to no
limit), though there is a danger of confusing people with too many
options.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
