Комментарии 16
Есть староватое, но работающее решение от OSM
https://github.com/Overv/openstreetmap-tile-server
Почему его не стали использовать?
Передать mbtiles проще, чем разворачивать postgis и мучиться с импортом на стороне заказчика.
Собственно и поделки на node/go не к чему, когда есть небольшой модуль для apache.
Да и скрипты обновления самописные зачем, есть же osmupdate
Передается pbf , тоже самое что mbtiles, postgres в докере, как и osmupdate , импорт одной командой.
Если так рассуждать, то зачем тогда вообще эта прослойка, клиент и так всё сам может сделать.
pbf не совсем то же самое, что mbtiles. pdf используются в качестве исходных данных для mbtiles, которые затем передаются заказчику и могут использоваться в закрытом контуре без лишних манипуляций с postgres, а обычной заменой файла mbtiles на новый. Подобный подход к организации работы с гео-данными снимает необходимость с заказчика разворачивать Postgres там где он не нужен.
Собственно и поделки на node/go не к чему, когда есть небольшой модуль для apache.
В инфраструктуре Аврора Центр нет Apache, плюс его использование снижает гибкость в работе с mbtiles, если потребуются какие-то изменения. Поэтому мы не можем использовать его в качестве сервера для mbtiles-файлов. Но там, где есть возможность его использования - это хороший вариант.
Да и скрипты обновления самописные зачем, есть же osmupdate
Мы используем самописные скрипты, так как сами определяем какие именно обновления и каких регионов нам необходимы. У нас кастомная карта собранная из разных регионов и частей регионов. Это одна из причин, почему нам приходится кастомизировать тулчейн обновлений. Так же в файлах обновлений мы ищем нецензурную лексику или другой неприемлемый контент. Если такая тонкая работа с обновлениями не требуется, то osmupda - это отличный вариант.
если потребуются какие-то изменения
Доработать на го проще чем на си, ну может быть, хотя кому как.
У нас кастомная карта собранная из разных регионов и частей регионов
Не понятно как это влияет на невозможность применить osmupdate
Не понятно как это влияет на невозможность применить osmupdate
После того, как мы вручную выкачиваем файлы обновлений, мы запускаем прикреплённый к статье python-скрипт для валидации данных в этих обновлениях. Кажется, что с osmupdate у нас не получилось бы проверять файлы обновлений на наличие деструктивных данных после скачивания, а пришлось бы проверять целый pbf уже после его обновления, что потребовало бы куда больше времени, чем проверка небольших файлов обновлений.
Это был единичный эпизод. Файлы обновления можно проверить уже постфактум, после обновления дампа. И если там что-то крамольное то... а собственно что вы в этом случае делаете?
Это был единичный эпизод.
Не совсем понятно, почему Вы думаете, что это был единичный эпизод. Но даже если так, то, кажется, никто не может дать гарантий, что в будущем эта ситуация не повторится
что вы в этом случае делаете?
Не применяем обновления и мониторим. Когда данная ситуация исправлена пайп по обновлению автоматически проходит.
Практика показывает, что за 15 лет таких случаев можно пересчитать по пальцам руки.
И то есть выходит, что абсолютно никакой разницы:
обновить дамп, проверить дельту на гадости, выпустить в прод;
проверить, ждать, проверить, ждать..., проверить, обновить пропуски, выпустить в прод.
Притом, вот только что замерил, моя проверка России заняла 3 минуты, это вообще не то время, чтобы ради этого городить велосипеды.
Мы искали решение, которое работает с mbtiles, написано на компилируемом языке и может быть адаптировано под нашу архитектуру. По этим причинам, мы не нашли предложенное вами решение, а модифицировали mbtiles-go и стали использовать его.
Меня интересует выбор Go вместо JavaScript с точки зрения требования верификации. Почему в вашем случае верификация является столь жёстким требованием? Значит ли это, что любые библиотеки на JavaScript запрещены в проекте из соображений безопасности? Как проводится верификация в Go?
У меня есть друг, который выбрал методы формальной верификации в качестве темы своей бакалаврской работы, но я всё ещё не понимаю, как это применяется в реальных условиях. Поэтому мне этот вопрос очень интересен
Меня интересует выбор Go вместо JavaScript с точки зрения требования верификации.
Если вы имели в виду сертификацию - то всё просто. Как и было написано в статье, для интерпретируемого языка нужен интерпретатор и при сертификации продукта нужно либо импользовать уже сертифицированный интерпретатор, либо сертифицировать его своими силами и, как можно понять: сертификация своими силами, например, движка JavaScript это очень сложная и долгая задача.
Почему в вашем случае верификация является столь жёстким требованием?
Сертифицированные сборки Аврора Центр поставляются в государственные структуры, которые требуют у продукта наличия сертификата ФСТЭК/ФСБ.
Значит ли это, что любые библиотеки на JavaScript запрещены в проекте из соображений безопасности?
Нет, если они не выполняются на стороне Аврора Центр. Например файлы для front-end'а написаны на TypeScript, но так как это статические файлы и JS выполняется на стороне клиента (браузера пользователя) - они не участвуют в сертификации продукта. Но если говорить о безопасности - все уязвимости исправляются.
Как проводится верификация в Go?
Сертификация происходит примерно так: исходный код передается в сертифицирующий орган, где он проходит проверки соответствия и если в ходе проверок не было выявлено никаких нарушений, то этот код и сборки на его основе являются сертифицированными.
Не понятна логика, компилятор го ведь тоже может компилируя ваш код насувать туда плохого, или такое могут делать только разные питоны да ноджеэсы?
Уточнили у отдела ИБ, они дали свои комментарии:
1) То, что компилятор добавляет в бинарный файл проверяется при динамическом тестировании. При использовании интерпретатора это сделать гораздо сложнее, т.к. в данном случае нужно будет провести динамическое тестирование для множества интерпретаторов (если конечно такое реально) и явно фиксировать перечень интерпретаторов допустимых к использованию.
2) Необходимость использования доверенных интерпретаторов обусловлено требованиями ФСТЭК. Мы ориентируемся на компетенции и экспертизу ФСТЭК России.
Реализация self-hosted карт в закрытом контуре