Chris tells me they had a minor fire in the datacenter where the portal lives and they have to install some new servers and restore from backups so the portal (and www and wiki) will be out of service for some days until after the paying customers are back on line. This seems entirely reasonable to me; we can get along without it for a little while.
And again I want to say thanks to Chris for writing and hosting the portal and our other web sites. - Brian
Hi Brian,
Very reasonable indeed...
Glad it was minor...
73 jerry N9LYA
I see the portal back up but not seeing any of my API scripts working.. Did that not get restored yet?
-- Fredric Moses - W8FSM - WQOG498 fred@moses.bz
API is not back online yet, I should have time to sort it over the weekend.
Sent from my iPhone
On 23 Jul 2015, at 20:08, Fredric Moses fred@moses.bz wrote:
(Please trim inclusions from previous messages) _______________________________________________ I see the portal back up but not seeing any of my API scripts working.. Did that not get restored yet?
-- Fredric Moses - W8FSM - WQOG498 fred@moses.bz
Hello all,
Would it make sense to have a ampr-ripd like software for setting up tunnel routes, based on getting the routes via portal API instead of RIP broadcasts? Or such an option in the ampr-ripd daemon?
Marius, YO2LOJ
Marius,
I'm curious, what would be the advantage? It seems to me that you'd be trading one single point of failure for another. And from what I've seen, the RIP broadcasts have been more reliable.
BTW, we haven't switched over to ampr-ripd, yet. At first, there was the problem of routes timing out or trying to start up a machine when the rip broadcasts were down. Later there were problems with the routing updates missing many routes. I think that's all been fixed now. But prior to all that, we set up the munge scripts to run a couple times a day and, if FTP was down, either at startup or during one of the daily updates, we'd use the previous copy of the encaps file. We also checked it for size so if we got a runt file, we'd continue using the previous file. Running twice a day kept us up-to-date well enough for our purposes and we only went through the whole process of creating the routes if there were diffs between the current and previous versions. The ability to use the previous copy of the encaps file if we detected a problem has saved us many times over the last few years when there were problems with the RIP feed.
I mention that because we're essentially using the portal for the route updates, except we're getting them via FTP instead of the API. I know it's not exactly the same. But with all of the improvements to ampr-ripd, we're actually thinking of moving to RIP. That's why I'm curious why you'd suggest pulling the data from the portal.
Thanks, Michael N6MEF
-----Original Message----- From: 44net-bounces+n6mef=mefox.org@hamradio.ucsd.edu [mailto:44net- bounces+n6mef=mefox.org@hamradio.ucsd.edu] On Behalf Of marius@yo2loj.ro Sent: Thursday, July 23, 2015 1:05 PM To: AMPRNet working group 44net@hamradio.ucsd.edu Subject: [44net] Portal API: ampr routing based on portal info
(Please trim inclusions from previous messages) _______________________________________________ Hello all,
Would it make sense to have a ampr-ripd like software for setting up tunnel routes, based on getting the routes via portal API instead of RIP broadcasts? Or such an option in the ampr-ripd daemon?
Marius, YO2LOJ
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Michael,
You are right about that single point of failure. Now about the gateway - that was an unfortunate fire incident, which could affect any system with the same probability (which is low I would say).
What I thougt was that the portal is the primary source of information regarding routing/encap. Somehow it would make sense to use that. And it would allow to update on demand via a standard protocol - http/tcp in his case.
It was just an idea, after using Tom Hayward's Mikrotik script (which uses the portal API) for a while, with excelent results.
Marius, YO2LOJ
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Michael Fox (N6MEF) Sent: Friday, July 24, 2015 02:56 To: 'AMPRNet working group' Subject: Re: [44net] Portal API: ampr routing based on portal info
(Please trim inclusions from previous messages) _______________________________________________ Marius,
I'm curious, what would be the advantage? It seems to me that you'd be trading one single point of failure for another. And from what I've seen, the RIP broadcasts have been more reliable.
FYI
I am working on a HA solution for the portal with real-time replicated systems at separate geographical locations.
I'm looking at setting up a Mariadb Galera multi-master cluster with three hosts, two of which will also serve the portal, wiki & API.
Failover will be via short TTL DNS records but there would be no issue with scripts using the API polling one server then the other if they got no reply from the first.
Chris
On 26 Jul 2015, at 09:27, Marius Petrescu marius@yo2loj.ro wrote:
(Please trim inclusions from previous messages) _______________________________________________ Michael,
You are right about that single point of failure. Now about the gateway - that was an unfortunate fire incident, which could affect any system with the same probability (which is low I would say).
What I thougt was that the portal is the primary source of information regarding routing/encap. Somehow it would make sense to use that. And it would allow to update on demand via a standard protocol - http/tcp in his case.
It was just an idea, after using Tom Hayward's Mikrotik script (which uses the portal API) for a while, with excelent results.
Marius, YO2LOJ
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Michael Fox (N6MEF) Sent: Friday, July 24, 2015 02:56 To: 'AMPRNet working group' Subject: Re: [44net] Portal API: ampr routing based on portal info
(Please trim inclusions from previous messages) _______________________________________________ Marius,
I'm curious, what would be the advantage? It seems to me that you'd be trading one single point of failure for another. And from what I've seen, the RIP broadcasts have been more reliable.
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
For what it's worth, it might be worth assigning a /24 and setting that up as an Anycast subnet so users can just connect to a single IP which is advertised from multiple locations. Setup local health-check scripts that will cause a BGP failure if any of the local services (Wiki / Portal / API) fail.
Use the Anycast IP as the primary inbound server connection with some other public IP (or VPN) on the backside for database replication and management.
Alternatively there are a few load balancer vendors who do offer global load balancing using a combination of DNS and translation to allow physically diverse servers to answer a single URL, though they are probably a bit too heavy weight for AMPR and a bit too expensive.
-- Will
On 7/26/15 4:12 AM, Chris wrote:
I am working on a HA solution for the portal with real-time replicated systems at separate geographical locations.
Failover will be via short TTL DNS records but there would be no issue with scripts using the API polling one server then the other if they got no reply from the first.
Hello all,
Would it make sense to have a ampr-ripd like software for setting up tunnel routes, based on getting the routes via portal API instead of RIP broadcasts? Or such an option in the ampr-ripd daemon?
Marius, YO2LOJ
-
Brian Kantor -
Chris -
Fredric Moses -
Jerry Kutche (N9LYA) -
Marius Petrescu -
marius＠yo2loj.ro
-
Michael Fox (N6MEF) -
Will Gwin