It should be possible to define multiple <downloadurl>
tags for an element's <downloads>
in an update server definition. This would allow possibilities such as download mirrors, especially in the case of certain countries blocking access to the resources a download originates from.
Title |
|
||||||
Labels |
Added:
?
|
Thanks! This is really big problem: we cant access to update server from Russia so now we only can downloads updates and releases from gitHub manually. Its not what newcomers expect from modern CMS so we must do something to avoid security and reputation risks.
+1 I can't update sites hosted on Russian servers...
How will the old sites be updated? If this site is not available for automatic update now.
Recently switched to the Russian VPS the same problem sites are not updated.
Help Russian community :)
Maybe it's better to allow the installation of an alternative server with localization?
This problem significantly hinders the use of the system. Not everyone has realized what happened. People who need it soon will be a lot. Thanks for the Jooomla-community support.
+1. Alternative mirrors are very important cos there's no access to the update server from Russian Federation now
+1. Alternative mirrors from Russia
I dont think multiple tags are necessary: in this case we would have to modify JUpdate to parse and store them, then we would have to add some check (which is bad) to find working URL to pass to JoomlaupdateModelDefault.
Instead we сould just add to tag multiple URLs separated by, for example, semicolon. Then we should modify JoomlaupdateModelDefault::download existing check for actual download URL.
I don't confirm the issue being from Russia. I have no problem with Joomla updates from a Russian IP, neither from Joomla admin panel, nor when directly downloading update packages from s3-us-west-2.amazonaws.com. If necessary I can provide all information for testing.
Category | ⇒ | com_joomlaupdate |
Status | New | ⇒ | Discussion |
Status | Discussion | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-11-10 06:02:12 |
Closed_By | ⇒ | franz-wohlkoenig |
Closed_By | franz-wohlkoenig | ⇒ | joomla-cms-bot |
Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/18543
Title |
|
Status | Closed | ⇒ | New |
Closed_Date | 2017-11-10 06:02:12 | ⇒ | |
Closed_By | joomla-cms-bot | ⇒ |
Let's keep this open. The PR is at best a workaround, even if it means we have to make a B/C break in the API it should be possible to add more download URLs here without coming up with a new name for each tag.
Status | New | ⇒ | Discussion |
Or this #18553?
happy to see more than 1 PR coming out
hope this happen more often
If all PR was coming out please don't forget to close the Issue.
@franz-wohlkoenig PR solves only part of the problem with the inability to download the update. It is also necessary that, in the most updated Joomla updates, alternative download links are available.
@alikon More than one PR is caused by the fact that the problem with updates in Russia is very acute, although I personally liked to contribute, even if my PR is not accepted.
Agreed with @Septdir: we can create a bunch of PR, but without alternative mirrors everything is useless.
Well, we're in a chicken and egg problem. Even if we wanted to use GitHub as a mirror (as right now it's the only other resource we have that can handle the traffic scale without another dedicated platform), we can't because core has no way to be told "if this location fails try another one". So this is at least helping with giving file mirroring capabilities, then internally we can work to ensure we have appropriate mirrors set up (maybe just having our downloads site and GitHub are enough, but both are on AWS S3 architecture so we're screwed if someone just flat out blocks the entirety of S3 instead of specific regions/buckets).
So it's a step forward and personally I'm glad to see multiple PRs for the idea because it gives us a chance to look at different ways to implement the approach instead of accepting the first idea that works.
@mbabker Thanx! Glad that you didn't remain indifferent to our problem.
@mbabker, i agree what GitHub is good mirror in current situation, but problem is time lag - new stable releases didn't appear here in same time as on main downloads site, so for us it will not solve the problem. Especially in terms of critical updates. Is it possible to put releases on GitHub on same time?
@effrit If we are talking about updating joomla, I think that the second mirror should not be tied to a third-party resource. And should download directly from ip joomla.org, because github can also block.
In most cases, the main mirror will be available, so there should not be any problems.
IMHO.
The not showing up on GitHub thing was all me, I just ran into a time crunch Tuesday morning made worse by a combination of non-Joomla related stress issues so I didn't get to publish that when I wanted to.
As for a mirror on our domain I'll do some research into a reasonable solution for that. It probably will be using our update.joomla.org platform as it's already a dedicated system in hour hosting architecture and is on a CDN so can help with not putting too much stress on that server.
So I've been thinking things through a little bit, and I think we actually should take the opportunity to deprecate <downloadurl>
and replace it with a functionally similar <download>
tag. I also think we can use the new tag and define standard attributes and values and actually use that data in updates (like right now type="full"
is basically ignored), that would actually help with an open issue of not being able to serve our smaller patch packages for core updates right now.
I know this is a bit of a change in direction but thinking about it using a new tag designed to be a collection element versus a single item lets us also address other architectural shortcomings needing attention without being majorly disruptive to extensions (well until the old tag goes away).
@mbabker, seems like we have a plan now. Maybe it will be right thing to implement #18547 PR and make release for testing?
@mbabker, seems like we have a plan now. Maybe it will be right thing to implement #18547 PR and make release for testing?
@mbabker
I believe that the entire current system of updates, or rather the xml file, does not fit well. I would have completely redesigned it (I thought about it for a long time when I wrote a component of updates for my project), I would also share kernel updates from updating extensions. Well and still probably 10 offers on this this account. If you want to talk about this, we can contact you and discuss everything personally.
But firstly, in the current situation, we need a quick solution to the problem.
Secondly, any changes in the update mechanism are threatened with refusals of updates of extensions. And other consequences.
IMHO
"...we're screwed if someone just flat out blocks the entirety of S3 instead of specific regions/buckets)."
Actually what is blocked is something like https://s3-us-west-2.amazonaws.com/poker888...or...whatever
Some ISPs in Russia have no technical means to block a single https page. That's why they block a whole domain. This story dates back to early 2016. I mean it's a matter to change ISP since a percentage of unlucky people is very low in Russia.
Well I found one of the sites that you can check these things on and found it was only that region. Which is good for now. But like I said, it'd be major trouble (for a lot of people) if instead of blocking a specific AWS region/subdomain the entire AWS domain were blocked.
@mbabker, this is really problem now. the official site is
http://blocklist.rkn.gov.ru/
and it show s3-us-west-2.amazonaws.com as blocked, so internet and hosting providers just tell us 'its law, we cant do anything about it'.
so we wait for solution!
please dont listen caprom, he told peoples what there is no problem because he have not it.
and his 'minority' came on our Russian forum every day!
I'm experiencing the same problem, many sites are not updated. The decision can be in the near future?
Any news?
For a shortterm solution it looks like the OSM decided the following:
Will be migrating AWS storage of downloads to another region to get around the restrictions in place by some countries
But i have no more details like this nor what the current status is about the migration.
Status | Discussion | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-12-02 17:12:38 |
Closed_By | ⇒ | wilsonge |
Thanks! That is the top issue for Russian community at the moment. Joomla update server is blocked on the territory of the Russian Federation by the decision of the state Agency (particularly s3-us-west-2.amazonaws.com).
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/18543.