Server not found #9
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Do rvm install before cartodb specific steps, so rebuild is faster.
Dockerfile CMD is run in non-interactive shell, so /etc/bash.bashrc is not sourced.
Organization can be used to share maps between members and because members uses same db an remote schema only has to be created once. A remote schema is a schema from a remote database server which can be made accessable using foreign data wrapper.
Updated configs to master branch of Cartodb repos.
- Allow avatar to be uploaded to local fs. - Renamed star avatar - Allow uploads up to 100Mb file size
Moved config files down.
Run create_dev_user twice, if fails on google api key first time running seconds makes in complete successfully.
Uploading files failed due to org2ogr2 no able to find gdal data.
Geocoder is not working at the moment.
Bugfixes for api version/url and regexps
Also trigger new build on DockerHub to get fix of CartoDB/carto.js#2161
To deter users from building the image themselves, because most times it is easier/quicker to pull the image from Docker Hub.
Before, the Dockerfile was installing the latest bundler version, which is only compatible with Ruby >= 2.3.0. I've changed the bundler version to 1.17.3, which requires Ruby >= 1.8.7. Version info here: https://rubygems.org/gems/bundler/versions/1.17.3
Specify bundler version
Switched to yarn to install deps in flat hierarchy instead of npms nested
Update Dockerfile with npm install, not yarn
Similar to Windshaft-cartodb see #75
I've combined the core nginx.conf with the proxy config, which all goes into /etc/nginx/nginx.conf. I've made a number of changes: * Nginx now proxies both SQL API and Windshaft requests through Varnish. * Nginx adds a custom HTTP header, X-Carto-Service, so that Varnish can differentiate between backends (since it can't do so based on incoming port). * I've modified the primary Nginx log format to include more information on how requests are being proxied--you can now see the upstream address for proxied requests. * I've added the `proxy_no_cache` and `proxy_cache_bypass` directives to the Windshaft and SQL API proxy sections. Without those directives, Nginx may attempt to act as a cache, returning 304 Not Modified for resources that more accurately should be cached by Varnish (whose cache is invalidated via a Postgres trigger for updated metadata).
I commented out the entire 'invalidation_service' section from app_config.yml. It _should_ be sufficient to set 'enabled' to false in that block, in order to prevent the Redis/Resque based invalidation service from being used inside the postgres trigger for invalidating cache items, but it's actually easier to just comment out the whole block. See this portion of the Carto code for reference: https://github.com/CartoDB/cartodb/blob/05a05fd6959bf4cc42480daec08d28449532cd8e/app/models/user/db_service.rb#L1062-L1070 The branch we want to go down in that code is the middle one--we want to end up with `create_function_invalidate_varnish_http` running. That will create a postgres trigger based on hitting the Varnish server's HTTP listener, which is running on 6081. (You could have it hit the telnet port by taking the third branch of that code, but given that telnet isn't included in later Varnish versions, best not to.) You want to avoid the first branch of that code, `create_function_invalidate_varnish_invalidation_service`, because it includes this line: https://github.com/CartoDB/cartodb/blob/05a05fd6959bf4cc42480daec08d28449532cd8e/app/models/user/db_service.rb#L1601 That's calling a custom Redis command, `TCH`, which is defined in a repo that Carto has not open sourced--meaning the 'invalidation service' (as a Redis job queue for the Resque job runner) can't be used in open source Carto (unless you reverse engineer the Redis commands it uses.)
The previous version of this file was enough to cache requests for the SQL API, but unfortunately no traffic was ever reaching Varnish to be cached. Nginx was proxying directly to the SQL API port, and Varnish was set to listen on 6081, so it wasn't able to intercept those requests. I updated the Nginx proxy config to aim at 6081 for requests to both SQL API and Windshaft, so now Varnish is receiving traffic. However, in order to know which backend to send traffic to, I had to add a custom HTTP header in the Nginx proxy pass. That header is picked up in the `vcl_recv` varnish subroutine and used to switch between backends. Additionally I've added logic for controlling what hosts can issue an HTTP PURGE command--in this case just localhost, since everything is on a single image. The purges will typically come from a Postgres trigger. As an overview of the purge related changes, see the Varnish docs here: https://varnish-cache.org/docs/3.0/tutorial/purging.html#http-purges
Update caching
This is a fix for the MX record check on email domains for the org setup.
Fix for Dev_User for MX Record Check
Fix for CartoDB MX Record check
Fix Dev_User for MX Record Check
Fixes #80
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello - not sure what the problem is but after a successful install just now, going to:
http://cartodb.localhost
or
http://cartodb.localhost/user/admin4example/organization
results in a server not found error.
I may be missing something but it doesn't look like it is working as it should now.
Thanks,