Не знаю, о чём вы говорите. Снапшоты вивальди теряли профайл раза три за пару месяцев и я именно после одной из потерь перестал пытаться ими пользоваться. Синхронизации в Vivaldi не было, экспортировать постоянно данные в другие браузеры, которые не теряют профиль — муторно. В итоге было проще от него отказаться, т.к. постоянно импортировать профиль из других браузеров и постоянно терять что-либо новое возникшее во время работы с ним и перелопачивать все настройки — напрягает.
Импортируйте. Кто же мешает? :-)
Ну вот я и спросил — есть ли такая возможность на примере отсутствия её в FF.
Вы о чём? Какая может быть автоматизация в удалении личных данных?
Из ваших слов (сам ещё не тестил снапшот) я понял, что пользователю нужно понять причину и следствие, после чего самостоятельно очистить данные синхронизации и инициировать на одной из машин синхронизацию с новым ключом.
Поэтому я написал, что было бы логично пользователю предоставить некий интерфейс для смены ключа, где во-первых, будет объяснение, чем это сулит, во-вторых, все нужные процессы после получения согласия на такую операцию будут запущены автоматически. То есть, грубо говоря, ввести новый ключ, согласиться на потенциально опасную операцию и получить ожидаемый результат. Если всё уже так и работает — чудесно.
Затем чтобы создать пользователя внутри контейнера с нужным UID, например. Ему там внутри практически всё равно, а я снаружи смогу быть владельцем файлов.
Проблема с доступом для пользователя, под которым я работаю и который запускает контейнеры.
У меня UID — 1000, допустим. У postgres внутри контейнера он другой. В итоге файлы создаются на диске с UID из контейнера и я со своим UID=1000 не могу получить к ним доступ в хостовой системе.
Насколько мне известно, есть два подхода решения этой проблемы:
— (популярный) пробросить UID в контейнер чтобы пользователь, под которым бегает демон (например, postgres) создался с этим UID
— (странный, костыльный, не особо гибкий) маппер UID для Docker, который работает на уровне демона и содержит карту UID внутри контейнеров и UID на хостовой системе которым они соответстуют и, соответственно, разруливает это.
Моя проблема, если мне не изменяет память, была в том, что я хотел настроить поднятие стека в Docker, но из Docker Compose не мог пробросить в контейнер UID пользователя, с которым нужно создавать пользователя внутри контейнера.
Тестовые сборки просто обязаны это делать время от времени :-)
Сижу на Opera Developer года три или четыре. Профайл терялся только один раз — из-за бага.
Зависит от того, в каких каталогах хранятся пользовательские файлы в тестовых сборках других браузеров. Vivaldi «обшаривает» на вопрос импорта стандартные каталоги программ.
Ну вот, например, Opera Developer. Я бы хотел оттуда попробовать импортировать данные.
Другими словами, перед сменой пароля нужно удалить все данные с сервера, а после смены пароля загрузить их из браузера снова.
То есть, сейчас процесс никак не автоматизирован? Надеюсь, в будущем этот процесс будет более удобен?
Есть немного оффтоп-вопросов:
1. Тестовые сборки Vivaldi всё ещё могут в любой момент при обновлении потерять профайл?
2. Vivaldi может импортировать данные из нестабильных версий браузеров? Например, Firefox не видит Opera Developer в упор, что достаточно печально, учитывая, что последняя установлена как браузер по умолчанию.
3. Учитывая ваши (команды Vivaldi) слова о том, как работает синхронизация и об использовании сквозного шифрования, возникает вопрос. Как поведёт себя браузерная синхронизация, если пользователь захочет сменить ключ шифрования? С моей точки зрения тут неоднозначная ситуация как вести себя браузеру и серверу. Например, если согласно словам разработчиков пушатся на сервер только изменения, то может получиться так, что на сервере прилетит изменение зашифрованное новым ключом при том, что все остальные данные зашифрованы старым. Или же при смене ключа на одном из браузеров регистрируется событие смены ключа и пушатся все данные целиком? Тогда как поведут себя другие инстансы в этой ситуации?
Последний раз, когда пробовал работать с официальным образом PostgreSQL, также были проблемы с доступом к файлам. Плюс было не очень понятно, как из docker-compose.yml универсально прокидывать юзера не хардкодя его UID — ведь этот конфиг могут запускать люди с разными UID, а не только 1000.
С того момента, правда, вышла уже третья версия схемы compose. Возможно, там это решено — нужно посмотреть.
Пробовал 10 версию ещё с беты, в целом приятно, но пока пришлось откатиться на 9.6, т.к. Doctrine DBAL пока не умеет работать с новым видом хранения сиквенсов, а следовательно, ломаются миграции (генерация).
Лично я, когда ещё задавал вопросы на Тостере, пришёл к выводу, что туда практически нет смысла писать сложные вопросы с большим количеством деталей — лучше это делать сразу на StackOverflow или профильных форумах.
На мой взгляд, Тостер оказался (именно по факту) наиболее эффективен для новичков, которые ещё плохо разбираются в теме, но уже не ленятся что-то сделать сами.
Понятное дело. Но это создаёт необходимость купить VPN/VPS.
Кстати, выше я вам ответил совсем не на то (мой косяк — отвлекался пока читал его). Так что предмет спора отсутствует.
Не знаю, о чём вы говорите. Снапшоты вивальди теряли профайл раза три за пару месяцев и я именно после одной из потерь перестал пытаться ими пользоваться. Синхронизации в Vivaldi не было, экспортировать постоянно данные в другие браузеры, которые не теряют профиль — муторно. В итоге было проще от него отказаться, т.к. постоянно импортировать профиль из других браузеров и постоянно терять что-либо новое возникшее во время работы с ним и перелопачивать все настройки — напрягает.
Ну вот я и спросил — есть ли такая возможность на примере отсутствия её в FF.
Из ваших слов (сам ещё не тестил снапшот) я понял, что пользователю нужно понять причину и следствие, после чего самостоятельно очистить данные синхронизации и инициировать на одной из машин синхронизацию с новым ключом.
Поэтому я написал, что было бы логично пользователю предоставить некий интерфейс для смены ключа, где во-первых, будет объяснение, чем это сулит, во-вторых, все нужные процессы после получения согласия на такую операцию будут запущены автоматически. То есть, грубо говоря, ввести новый ключ, согласиться на потенциально опасную операцию и получить ожидаемый результат. Если всё уже так и работает — чудесно.
Что мешает перехватить вашу линию и нажать единичку за вас? СОРМ, скорее всего, такое позволяет.
У меня UID — 1000, допустим. У postgres внутри контейнера он другой. В итоге файлы создаются на диске с UID из контейнера и я со своим UID=1000 не могу получить к ним доступ в хостовой системе.
Насколько мне известно, есть два подхода решения этой проблемы:
— (популярный) пробросить UID в контейнер чтобы пользователь, под которым бегает демон (например, postgres) создался с этим UID
— (странный, костыльный, не особо гибкий) маппер UID для Docker, который работает на уровне демона и содержит карту UID внутри контейнеров и UID на хостовой системе которым они соответстуют и, соответственно, разруливает это.
Моя проблема, если мне не изменяет память, была в том, что я хотел настроить поднятие стека в Docker, но из Docker Compose не мог пробросить в контейнер UID пользователя, с которым нужно создавать пользователя внутри контейнера.
Сижу на Opera Developer года три или четыре. Профайл терялся только один раз — из-за бага.
Ну вот, например, Opera Developer. Я бы хотел оттуда попробовать импортировать данные.
То есть, сейчас процесс никак не автоматизирован? Надеюсь, в будущем этот процесс будет более удобен?
Спасибо за ответы.
1. Тестовые сборки Vivaldi всё ещё могут в любой момент при обновлении потерять профайл?
2. Vivaldi может импортировать данные из нестабильных версий браузеров? Например, Firefox не видит Opera Developer в упор, что достаточно печально, учитывая, что последняя установлена как браузер по умолчанию.
3. Учитывая ваши (команды Vivaldi) слова о том, как работает синхронизация и об использовании сквозного шифрования, возникает вопрос. Как поведёт себя браузерная синхронизация, если пользователь захочет сменить ключ шифрования? С моей точки зрения тут неоднозначная ситуация как вести себя браузеру и серверу. Например, если согласно словам разработчиков пушатся на сервер только изменения, то может получиться так, что на сервере прилетит изменение зашифрованное новым ключом при том, что все остальные данные зашифрованы старым. Или же при смене ключа на одном из браузеров регистрируется событие смены ключа и пушатся все данные целиком? Тогда как поведут себя другие инстансы в этой ситуации?
С того момента, правда, вышла уже третья версия схемы compose. Возможно, там это решено — нужно посмотреть.
На мой взгляд, Тостер оказался (именно по факту) наиболее эффективен для новичков, которые ещё плохо разбираются в теме, но уже не ленятся что-то сделать сами.
lowendstock.com
Когда статья? :)
Кстати, выше я вам ответил совсем не на то (мой косяк — отвлекался пока читал его). Так что предмет спора отсутствует.