Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
TSO - frying pan to fire?
38 views
Skip to first unread message
Roland Perry
May 27, 2017, 10:09:11 AM5/27/17
to
I've seen lots of recommendations here to switch to TSO, but having
tried this, I find their system very difficult.
Not just incomprehensible errors like:
"Fatal error: Call to a member function assign() on string in
/home/billing/htdocs/includes/classes/WHMCS/ClientArea.php on line 0"
But almost nothing I wish to do via their custom-DNS facility, works for
me.
At best they say "we'll have to do that for you", at worst "sorry we
don't support that".
And when they "do something for me" they never explain: why what they do
differs from what I was trying to do; nor is there any comprehension/
warning in their support staff that what they just for me did broke
other things.
Today's example was apparently needing to specify their email server by
IP address rather than domain name.
The underlying issue appears to be that their Custom-DNS dialogue is
entirely a wish-list, and has no user feedback about whether the wish
was granted.
So my main question: does TSO have a screen which says what my DNS
setting currently *are*?
--
Roland Perry
tried this, I find their system very difficult.
Not just incomprehensible errors like:
"Fatal error: Call to a member function assign() on string in
/home/billing/htdocs/includes/classes/WHMCS/ClientArea.php on line 0"
But almost nothing I wish to do via their custom-DNS facility, works for
me.
At best they say "we'll have to do that for you", at worst "sorry we
don't support that".
And when they "do something for me" they never explain: why what they do
differs from what I was trying to do; nor is there any comprehension/
warning in their support staff that what they just for me did broke
other things.
Today's example was apparently needing to specify their email server by
IP address rather than domain name.
The underlying issue appears to be that their Custom-DNS dialogue is
entirely a wish-list, and has no user feedback about whether the wish
was granted.
So my main question: does TSO have a screen which says what my DNS
setting currently *are*?
--
Roland Perry
Chris S
May 28, 2017, 11:25:26 AM5/28/17
to
On Sat, 27 May 2017 15:07:15 +0100, Roland Perry <rol...@perry.co.uk>
wrote:
Depends on what package you are on, eg cloud, cpanel etc. I have circa
7 domains running under their cloud set-up. The client side email IP
is displayed in the left hand side of each manage website section of
the cloud dashboard. There is a custom DNS panel for each website
which although its purpose is to enable changes, I assume the
displayed records reflect the current zone file for the domain in
question. However, I have not needed to customise Tsohost DNS at all
during or after migrating domains from Gradwell; all 'migratory' DNS
modifications were made to Gradwell DNS records.
Chris S
wrote:
7 domains running under their cloud set-up. The client side email IP
is displayed in the left hand side of each manage website section of
the cloud dashboard. There is a custom DNS panel for each website
which although its purpose is to enable changes, I assume the
displayed records reflect the current zone file for the domain in
question. However, I have not needed to customise Tsohost DNS at all
during or after migrating domains from Gradwell; all 'migratory' DNS
modifications were made to Gradwell DNS records.
Chris S
Roland Perry
May 29, 2017, 4:04:14 AM5/29/17
to
In message <r4plichc1ul1gjld8...@4ax.com>, at 16:25:24 on
Sun, 28 May 2017, Chris S <ugje...@sneakemail.com> remarked:
had to be a hostname and plucked the right one from the air (maybe it's
in a help file somewhere, but I've rather lost the will to live inside
their spaghetti website).
>>The underlying issue appears to be that their Custom-DNS dialogue is
>>entirely a wish-list, and has no user feedback about whether the wish
>>was granted.
>>
>>So my main question: does TSO have a screen which says what my DNS
>>setting currently *are*?
>
>Depends on what package you are on, eg cloud, cpanel etc. I have circa
>7 domains running under their cloud set-up. The client side email IP
>is displayed in the left hand side of each manage website section of
>the cloud dashboard. There is a custom DNS panel for each website
>which although its purpose is to enable changes, I assume the
>displayed records reflect the current zone file for the domain in
>question. However, I have not needed to customise Tsohost DNS at all
>during or after migrating domains from Gradwell; all 'migratory' DNS
>modifications were made to Gradwell DNS records.
I'm on cpanel, which I perhaps mistakenly thought would give me more
nuanced control over the DNS settings.
After now having had four chat sessions, I can add to the list of woes
that having talking me through the settings for one DNS entry, all four
failed to say "but that will break this other entry, which I hope you
therefore are considering changing to X".
As they *do* have all the DNS entries (rather than a potentially sterile
wish-list) in front of them, it seems a bit pointless, because all it
does is create yet another support ticket.
--
Roland Perry
Sun, 28 May 2017, Chris S <ugje...@sneakemail.com> remarked:
>On Sat, 27 May 2017 15:07:15 +0100, Roland Perry <rol...@perry.co.uk>
>wrote:
>
>>I've seen lots of recommendations here to switch to TSO, but having
>>tried this, I find their system very difficult.
>>
>>Not just incomprehensible errors like:
>>
>>"Fatal error: Call to a member function assign() on string in
>>/home/billing/htdocs/includes/classes/WHMCS/ClientArea.php on line 0"
>>
>>But almost nothing I wish to do via their custom-DNS facility, works for
>>me.
>>
>>At best they say "we'll have to do that for you", at worst "sorry we
>>don't support that".
>>
>>And when they "do something for me" they never explain: why what they do
>>differs from what I was trying to do; nor is there any comprehension/
>>warning in their support staff that what they just for me did broke
>>other things.
>>
>>Today's example was apparently needing to specify their email server by
>>IP address rather than domain name.
Which didn't work, and the next chat session a different guy told me it
>wrote:
>
>>I've seen lots of recommendations here to switch to TSO, but having
>>tried this, I find their system very difficult.
>>
>>Not just incomprehensible errors like:
>>
>>"Fatal error: Call to a member function assign() on string in
>>/home/billing/htdocs/includes/classes/WHMCS/ClientArea.php on line 0"
>>
>>But almost nothing I wish to do via their custom-DNS facility, works for
>>me.
>>
>>At best they say "we'll have to do that for you", at worst "sorry we
>>don't support that".
>>
>>And when they "do something for me" they never explain: why what they do
>>differs from what I was trying to do; nor is there any comprehension/
>>warning in their support staff that what they just for me did broke
>>other things.
>>
>>Today's example was apparently needing to specify their email server by
>>IP address rather than domain name.
had to be a hostname and plucked the right one from the air (maybe it's
in a help file somewhere, but I've rather lost the will to live inside
their spaghetti website).
>>The underlying issue appears to be that their Custom-DNS dialogue is
>>entirely a wish-list, and has no user feedback about whether the wish
>>was granted.
>>
>>So my main question: does TSO have a screen which says what my DNS
>>setting currently *are*?
>
>Depends on what package you are on, eg cloud, cpanel etc. I have circa
>7 domains running under their cloud set-up. The client side email IP
>is displayed in the left hand side of each manage website section of
>the cloud dashboard. There is a custom DNS panel for each website
>which although its purpose is to enable changes, I assume the
>displayed records reflect the current zone file for the domain in
>question. However, I have not needed to customise Tsohost DNS at all
>during or after migrating domains from Gradwell; all 'migratory' DNS
>modifications were made to Gradwell DNS records.
nuanced control over the DNS settings.
After now having had four chat sessions, I can add to the list of woes
that having talking me through the settings for one DNS entry, all four
failed to say "but that will break this other entry, which I hope you
therefore are considering changing to X".
As they *do* have all the DNS entries (rather than a potentially sterile
wish-list) in front of them, it seems a bit pointless, because all it
does is create yet another support ticket.
--
Roland Perry
Bob Evans
May 29, 2017, 7:14:49 AM5/29/17
to
In article <+MjsBEfT...@perry.co.uk>, Roland Perry
<rol...@perry.co.uk> wrote
associated with the domain that you are considering.
You can check this by logging in to my.tsohost.com. Choose 'My Domains'
and click on the spanner button next to the domain in question. Then
click 'Nameservers' (from menu on LHS).
If the nameservers are set to ns1.tsodns.com, ns2.tsodns.com then the
effective DSN zone file is the one that you can inspect and edit via the
'Custom DNS Records' button (on LHS).
On the other hand, if the nameservers for the domain in question are set
to ns1.tsohost.co.uk, ns2.tsohost.co.uk, etc., then the effective zone
file is the one that you can see/edit in the Cloud Hosting control panel
at control.gridhost.co.uk (or Cpanel equivalent if applicable).
HTH,
--
Bob Evans
<rol...@perry.co.uk> wrote
>does TSO have a screen which says what my DNS setting currently *are*?
Yes, of course. But where to look depends on which nameservers are
associated with the domain that you are considering.
You can check this by logging in to my.tsohost.com. Choose 'My Domains'
and click on the spanner button next to the domain in question. Then
click 'Nameservers' (from menu on LHS).
If the nameservers are set to ns1.tsodns.com, ns2.tsodns.com then the
effective DSN zone file is the one that you can inspect and edit via the
'Custom DNS Records' button (on LHS).
On the other hand, if the nameservers for the domain in question are set
to ns1.tsohost.co.uk, ns2.tsohost.co.uk, etc., then the effective zone
file is the one that you can see/edit in the Cloud Hosting control panel
at control.gridhost.co.uk (or Cpanel equivalent if applicable).
HTH,
--
Bob Evans
Chris S
May 29, 2017, 9:49:03 AM5/29/17
to
problems. Seems my.tsohost.com has had a facelift since I last
accessed it. i shall have a wander round.
Chris S
Roland Perry
May 30, 2017, 6:02:24 AM5/30/17
to
In message <+qEDe7Ck...@cygnus.rejectifspam.lichtech.co.uk>, at
12:14:44 on Mon, 29 May 2017, Bob Evans
<newsab...@deleteifspam.lichtech.co.uk> remarked:
settings. It's where I was when I placed the first of my four call to
them.
The information there is merely some kind of "wish list", which is not
fully posted/updated to the DNS server 'warts and all'.
Sometimes a whole line (in my case MX record) never gets sent to the DNS
server, which is very confusing when trying to debug and their techie
says "that's because you don't have an MX record" and I say "but but
but, I can see one in front of me, on the Custom DNS screen".
>On the other hand, if the nameservers for the domain in question are
>set to ns1.tsohost.co.uk, ns2.tsohost.co.uk, etc., then the effective
>zone file is the one that you can see/edit in the Cloud Hosting control
>panel at control.gridhost.co.uk (or Cpanel equivalent if applicable).
>
>HTH,
--
Roland Perry
12:14:44 on Mon, 29 May 2017, Bob Evans
<newsab...@deleteifspam.lichtech.co.uk> remarked:
>In article <+MjsBEfT...@perry.co.uk>, Roland Perry
><rol...@perry.co.uk> wrote
>>does TSO have a screen which says what my DNS setting currently *are*?
>
>Yes, of course. But where to look depends on which nameservers are
>associated with the domain that you are considering.
>
>You can check this by logging in to my.tsohost.com. Choose 'My Domains'
>and click on the spanner button next to the domain in question. Then
>click 'Nameservers' (from menu on LHS).
>
>If the nameservers are set to ns1.tsodns.com, ns2.tsodns.com then the
>effective DSN zone file is the one that you can inspect and edit via
>the 'Custom DNS Records' button (on LHS).
Sorry, but that's precisely what *isn't* a mirror of the actual DNS
><rol...@perry.co.uk> wrote
>>does TSO have a screen which says what my DNS setting currently *are*?
>
>Yes, of course. But where to look depends on which nameservers are
>associated with the domain that you are considering.
>
>You can check this by logging in to my.tsohost.com. Choose 'My Domains'
>and click on the spanner button next to the domain in question. Then
>click 'Nameservers' (from menu on LHS).
>
>If the nameservers are set to ns1.tsodns.com, ns2.tsodns.com then the
>effective DSN zone file is the one that you can inspect and edit via
>the 'Custom DNS Records' button (on LHS).
settings. It's where I was when I placed the first of my four call to
them.
The information there is merely some kind of "wish list", which is not
fully posted/updated to the DNS server 'warts and all'.
Sometimes a whole line (in my case MX record) never gets sent to the DNS
server, which is very confusing when trying to debug and their techie
says "that's because you don't have an MX record" and I say "but but
but, I can see one in front of me, on the Custom DNS screen".
>On the other hand, if the nameservers for the domain in question are
>set to ns1.tsohost.co.uk, ns2.tsohost.co.uk, etc., then the effective
>zone file is the one that you can see/edit in the Cloud Hosting control
>panel at control.gridhost.co.uk (or Cpanel equivalent if applicable).
>
>HTH,
--
Bob Evans
May 30, 2017, 2:26:51 PM5/30/17
to
In article <wjGfaxRB...@perry.co.uk>, Roland Perry
<rol...@perry.co.uk> wrote
more than 100 domains at TSOhost with zone files pointing to a mixture
of TSO dedicated servers and cloud server instances and have never
encountered such a problem. I must lead a charmed life.
One thought: If making DNS alterations to a domain that is already in
use, do you remember to wind down the TTL values on the affected records
well in advance of making the intended changes?
My experience is that the delay between making a change in the web
control panel and the resulting update of the "real" zone file is a
matter of seconds or a few minutes at most. But if the old DNS data is
cached (with the typical default TTL of 24 hours) all over the place
outside of TSO, then naturally it can take quite a while for the outside
world to catch up.
--
Bob Evans
<rol...@perry.co.uk> wrote
>>If the nameservers are set to ns1.tsodns.com, ns2.tsodns.com then the
>>effective DSN zone file is the one that you can inspect and edit via
>>the 'Custom DNS Records' button (on LHS).
>
>Sorry, but that's precisely what *isn't* a mirror of the actual DNS
>settings. It's where I was when I placed the first of my four call to
>them.
>
>The information there is merely some kind of "wish list", which is not
>fully posted/updated to the DNS server 'warts and all'.
That seems very weird (and annoying). On behalf of customers, I manage
>>effective DSN zone file is the one that you can inspect and edit via
>>the 'Custom DNS Records' button (on LHS).
>
>Sorry, but that's precisely what *isn't* a mirror of the actual DNS
>settings. It's where I was when I placed the first of my four call to
>them.
>
>The information there is merely some kind of "wish list", which is not
>fully posted/updated to the DNS server 'warts and all'.
more than 100 domains at TSOhost with zone files pointing to a mixture
of TSO dedicated servers and cloud server instances and have never
encountered such a problem. I must lead a charmed life.
One thought: If making DNS alterations to a domain that is already in
use, do you remember to wind down the TTL values on the affected records
well in advance of making the intended changes?
My experience is that the delay between making a change in the web
control panel and the resulting update of the "real" zone file is a
matter of seconds or a few minutes at most. But if the old DNS data is
cached (with the typical default TTL of 24 hours) all over the place
outside of TSO, then naturally it can take quite a while for the outside
world to catch up.
--
Bob Evans
Roland Perry
May 30, 2017, 3:44:18 PM5/30/17
to
In message <YwoqYcGU...@cygnus.rejectifspam.lichtech.co.uk>, at
19:26:28 on Tue, 30 May 2017, Bob Evans
<newsab...@deleteifspam.lichtech.co.uk> remarked:
update "nah, I don't want to do that". Or even "I tried, and it
wouldn't". Or even even "I tried, and this is now what it's set to, and
if that wasn't what you just asked for, then panic".
At least one could then investigate, even if it declined to say what
precise part of the proposed update was causing it indigestion.
>One thought: If making DNS alterations to a domain that is already in
>use, do you remember to wind down the TTL values on the affected
>records well in advance of making the intended changes?
That's a very outdated meme. In my case I was making the very first
changes to a domain that was in some sense 'parked'. But it also
involved switching to new DNS servers (the custom vs cpanel ones).
When requesting DNS, the only thing which causes a delay to kick in is
if someone else using the same ISP-DNS-server has caused the information
to be cached. If it's never been cached there, then the cache hasn't
been primed and the TTL hasn't yet kicked in.
>My experience is that the delay between making a change in the web
>control panel and the resulting update of the "real" zone file is a
>matter of seconds or a few minutes at most.
Only if the TSO system doesn't say "nah".
>But if the old DNS data is cached (with the typical default TTL of 24
>hours) all over the place outside of TSO, then naturally it can take
>quite a while for the outside world to catch up.
But a 'parked' domain isn't likely to be widely cached like that,
because no-one has any cause to browse it (or in my case send it any
email).
The DNS changes which enabled my 3rd party web hosting (which TSO said
probably quite correctly - in view of my own inability to - only *their*
techies could handcraft past their "nah-gatekeeper") took a while to
propagate via my wired broadband supplier, because I'd previously tried
browsing to the site, and got the stale[1] cached answer.
But switching to a completely unrelated mobile phone data connection,
with no cache yet primed for my domain, the intended result came up
immediately.
Similarly, using various third party DNS looking glasses, you wouldn't
expect them to have had their cache primed.
[1] MX 86400 which is 24hrs, but for no reason they care to explain, the
CNAME and A records they set by hand for me 3600 - an hour.
--
Roland Perry
19:26:28 on Tue, 30 May 2017, Bob Evans
<newsab...@deleteifspam.lichtech.co.uk> remarked:
>In article <wjGfaxRB...@perry.co.uk>, Roland Perry
><rol...@perry.co.uk> wrote
>>>If the nameservers are set to ns1.tsodns.com, ns2.tsodns.com then the
>>>effective DSN zone file is the one that you can inspect and edit via
>>>the 'Custom DNS Records' button (on LHS).
>>
>>Sorry, but that's precisely what *isn't* a mirror of the actual DNS
>>settings. It's where I was when I placed the first of my four call to
>>them.
>>
>>The information there is merely some kind of "wish list", which is not
>>fully posted/updated to the DNS server 'warts and all'.
>
>That seems very weird (and annoying). On behalf of customers, I manage
>more than 100 domains at TSOhost with zone files pointing to a mixture
>of TSO dedicated servers and cloud server instances and have never
>encountered such a problem. I must lead a charmed life.
It would of course help if the TSO Custom DNS page said, to a proposed
><rol...@perry.co.uk> wrote
>>>If the nameservers are set to ns1.tsodns.com, ns2.tsodns.com then the
>>>effective DSN zone file is the one that you can inspect and edit via
>>>the 'Custom DNS Records' button (on LHS).
>>
>>Sorry, but that's precisely what *isn't* a mirror of the actual DNS
>>settings. It's where I was when I placed the first of my four call to
>>them.
>>
>>The information there is merely some kind of "wish list", which is not
>>fully posted/updated to the DNS server 'warts and all'.
>
>That seems very weird (and annoying). On behalf of customers, I manage
>more than 100 domains at TSOhost with zone files pointing to a mixture
>of TSO dedicated servers and cloud server instances and have never
>encountered such a problem. I must lead a charmed life.
update "nah, I don't want to do that". Or even "I tried, and it
wouldn't". Or even even "I tried, and this is now what it's set to, and
if that wasn't what you just asked for, then panic".
At least one could then investigate, even if it declined to say what
precise part of the proposed update was causing it indigestion.
>One thought: If making DNS alterations to a domain that is already in
>use, do you remember to wind down the TTL values on the affected
>records well in advance of making the intended changes?
changes to a domain that was in some sense 'parked'. But it also
involved switching to new DNS servers (the custom vs cpanel ones).
When requesting DNS, the only thing which causes a delay to kick in is
if someone else using the same ISP-DNS-server has caused the information
to be cached. If it's never been cached there, then the cache hasn't
been primed and the TTL hasn't yet kicked in.
>My experience is that the delay between making a change in the web
>control panel and the resulting update of the "real" zone file is a
>matter of seconds or a few minutes at most.
>But if the old DNS data is cached (with the typical default TTL of 24
>hours) all over the place outside of TSO, then naturally it can take
>quite a while for the outside world to catch up.
because no-one has any cause to browse it (or in my case send it any
email).
The DNS changes which enabled my 3rd party web hosting (which TSO said
probably quite correctly - in view of my own inability to - only *their*
techies could handcraft past their "nah-gatekeeper") took a while to
propagate via my wired broadband supplier, because I'd previously tried
browsing to the site, and got the stale[1] cached answer.
But switching to a completely unrelated mobile phone data connection,
with no cache yet primed for my domain, the intended result came up
immediately.
Similarly, using various third party DNS looking glasses, you wouldn't
expect them to have had their cache primed.
[1] MX 86400 which is 24hrs, but for no reason they care to explain, the
CNAME and A records they set by hand for me 3600 - an hour.
--
Roland Perry
news
Jul 20, 2017, 4:36:50 PM7/20/17
to
In article <+MjsBEfT...@perry.co.uk>, Roland Perry
<rol...@perry.co.uk> writes
>I've seen lots of recommendations here to switch to TSO, but having
>tried this, I find their system very difficult.
Did you resolve your problems and are you happy to recommend TSO? It
>tried this, I find their system very difficult.
seems suitable for a single-domain, single-email address user like me -
and far cheaper than <G>
My computer-professional son who oversees such changes has a couple of
queries regarding my insistence on continuing use of Turnpike, however.
He worries that TP is locked to Port 25, which will restrict any move to
mobile broadband in future. I pointed him at guidance here on using
STunnel to overcome that. How do you handle this problem?
--
David Lawson
Roland Perry
Jul 23, 2017, 2:30:03 AM7/23/17
to
In message <qksMD+Gz...@davidlawson.co.uk>, at 20:44:51 on Thu, 20
Jul 2017, news <ne...@davidlawson.co.uk> remarked:
their support staff, who spent most of their time contradicting each
other.
> My computer-professional son who oversees such changes has a couple of
>queries regarding my insistence on continuing use of Turnpike, however.
>He worries that TP is locked to Port 25, which will restrict any move
>to mobile broadband in future. I pointed him at guidance here on using
>STunnel to overcome that. How do you handle this problem?
Currently, by continuing to use Gradwell, who accept authenticated port
25. On the back burner is a project I started about seven (gosh how time
flies) years ago which involves having an email relay program running on
a local otherwise life-expired netbook, and which would accept emails
from the Turnpike platform and then deliver them in various directions
(including port 465) based on some simple rules.
In effect very like stunnel, but running on a dedicated gateway PC.
The original need was a client who had a completely brain-dead (they
always are) anti-spam policy which required anyone using their domain in
an email address (either internally or externally) to inject through
their mail server inside their firewall.
A benefit from implementing it was that one could configure the gateway
to send emails *direct* to recipients who had their own mail servers,
without getting caught up by delays, relays and filtering in the core.
This came with extensive logging regarding the success (or otherwise) of
having completed the transfer.
--
Roland Perry
Jul 2017, news <ne...@davidlawson.co.uk> remarked:
>In article <+MjsBEfT...@perry.co.uk>, Roland Perry
><rol...@perry.co.uk> writes
>>I've seen lots of recommendations here to switch to TSO, but having
>>tried this, I find their system very difficult.
>
> Did you resolve your problems and are you happy to recommend TSO? It
>seems suitable for a single-domain, single-email address user like me -
>and far cheaper than <G>
It's currently stabilised, but I was astonished by the numpty-factor of
><rol...@perry.co.uk> writes
>>I've seen lots of recommendations here to switch to TSO, but having
>>tried this, I find their system very difficult.
>
> Did you resolve your problems and are you happy to recommend TSO? It
>seems suitable for a single-domain, single-email address user like me -
>and far cheaper than <G>
their support staff, who spent most of their time contradicting each
other.
> My computer-professional son who oversees such changes has a couple of
>queries regarding my insistence on continuing use of Turnpike, however.
>He worries that TP is locked to Port 25, which will restrict any move
>to mobile broadband in future. I pointed him at guidance here on using
>STunnel to overcome that. How do you handle this problem?
25. On the back burner is a project I started about seven (gosh how time
flies) years ago which involves having an email relay program running on
a local otherwise life-expired netbook, and which would accept emails
from the Turnpike platform and then deliver them in various directions
(including port 465) based on some simple rules.
In effect very like stunnel, but running on a dedicated gateway PC.
The original need was a client who had a completely brain-dead (they
always are) anti-spam policy which required anyone using their domain in
an email address (either internally or externally) to inject through
their mail server inside their firewall.
A benefit from implementing it was that one could configure the gateway
to send emails *direct* to recipients who had their own mail servers,
without getting caught up by delays, relays and filtering in the core.
This came with extensive logging regarding the success (or otherwise) of
having completed the transfer.
--
Roland Perry
0 new messages