Как настроить bridge в netplan Ubuntu 18.04?

Скажу откровенно запарился гадать. Сделал
apt-get install ifupdown
Подхватило старые настрой Сети и заработало.

Как понять значение TCP данных статистики?

hint000, благодаря вашему комментарию я наконец нашел ниточку сути.

In MySQL we have the typical behaviour that we open and close connections very often and rapidly. So we have very short-living connections to the server. This can lead in extreme cases to the situation that the maximum number of TCP ports are exhausted.

У меня действительно "висят" подключения к БД, но как об этом говорится, это нормальная практика в Веб. На сколько я помню, ОС убъет их когда посчитает нужным. Просто на другом сервере с аналогичными настройками такой полки нет. И портов около 64К в системе. Откуда тогда этот лимит ~8К

Как понять значение TCP данных статистики?

worker_connections 10000;

Как понять значение TCP данных статистики?

Это веб сервер. NGINX + php-fpm

Где лучше хранить JWT?

Александр Мелентьев, ни в куках, ни тем более в JWT не может быть никакой критически важной информации требующей хоть какого-либо шифрования или сокрытия. Если вы так делаете - вы поклонник плохих практик. Вам никто делать так не запрещает, ровно как и гомосексуалистам использовать свои дырки по своему усмотрению.

Где лучше хранить JWT?

xmoonlight, это токен авторизации. Он авторизует всё у кого он есть. Привязка к сессии или к клиенту да к чему угодно. Вставляете в тело токена свою привязку и всё. Он работает только с тем, к чему привязан, без вашей всей попоболи. Вы не понимаете сути JWT.

Где лучше хранить JWT?

xmoonlight, У хабра новая политика?) троллить Пользователей и постить Холиварные темы? Вы идете ко дну или уже там по элементарным причинам и такая "новая политика" вас точно не спасет.

Где лучше хранить JWT?

xmoonlight, зачем защищать JWT ? Я вроде с этого начал. Откройте хоть сраную википедию.

JSON Web Token (JWT) — это открытый стандарт (RFC 7519) для создания токенов доступа, основанный на формате JSON. Как правило, используется для передачи данных для аутентификации в клиент-серверных приложениях. Токены создаются сервером, подписываются секретным ключом и передаются клиенту, который в дальнейшем использует данный токен для подтверждения своей личности.

Он изначально безопасен. Его не нужно защищать. В нем подпись изначально имеется. Вы не понимаете сути и путаете новичков. JWT не должен шифроваться по определению. Там нет и не должно быть конфиденциальной информации. Вы тролль самый обычный.

Где лучше хранить JWT?

Для чего шифровать JWT ? - он не предназначен для конфиденциальной информации(ошибка 1). Токен изначально самоподписанный, ему не к чему сторонние подписи и ключи. Вы перечислили плохие практики для JWT (скорее банально троллинг). JWT по своей сути хранится считанные минуты.

Всё вами перечисленное привязывается к сессии когда необходима вся эта защита. Сам токен/ID сессии вкладывается внутрь JWT с любой другой необходимой информацией. Вы чешете горло через анус.

Рестарт ansible во время выполнения возможен?

Requirements
The below requirements are needed on the host that executes this module.

PyMySQL (Python 2.7 and Python 3.X), or
MySQLdb (Python 2.x)

Как правильно выстроить разработку и деплой сайта?

Самый простой и надежный способ: root у вашего nginx/apache указывать как ссылку на каталог текущей прод версии.

Отчасти бред. Давно есть инструменты для php https://github.com/deployphp/deployer - любые другие хоть ансибл хоть шеф. Что хотите - деплой одной командой хоть на сколь угодно серверов - один клик.

Как получить ID пользователя от Google или Yandex?

Кажется это то. В гуглк есть GCLID https://support.google.com/analytics/answer/103398... - и яндекс его даст из своего апи, если он имеется. Попробую поковырять. Кажется это то что надо. Хотя вроде и нет. Ведь это параметр визита.

Как получить ID пользователя от Google или Yandex?

Там вроде firebase внутри генерирует случайных хэш пользователя относительно вашей учетной записи. Тогда этот же пользователь но у меня будет иметь другой хэш. А отдельным запросом мы просто перекидываем этот хэш в ГА чтобы оно статистику скорректировало.

Когда пользователь авторизован, я же и так вижу его с любого устройства, хоть с тостера. А вот не авторизованый или с мультиаккаунтом. Помог бы сторонний/глобальный ID этого человека.

В чем причина постоянно умирающего SSD?

Диск в сервис сносите на тест. Скорее всего не в нем дело, хотя очень и очень на него похоже. Я сам в шоке был. Хорошо хоть гарантия на несколько лет была, мать даже ремонтировать не стали, просто поменяли. Но причины не сказали... Тайна какая-то.

Какую библиотеку использовать для REST запросов в JS?

REST имеет однотипные и предсказуемые URL - то есть, почти никогда не нужно писать весь URL, достаточно указать сущность, например user. Так вот, c инструментом конфигурирования АПИ можно сразу писать get('user') или post('user', data) - и всё.

Какую библиотеку использовать для REST запросов в JS?

Несколько АПИ серверов (микросервисы). Авторизация JWT почти везде. REST имеет однотипные и предсказуемые URL - то есть, почти никогда не нужно писать весь URL, достаточно указать сущность, например user. Так вот, c инструментом конфигурирования АПИ можно сразу писать get('user') или post('user', data) - и всё. Я уже почти полностью такой костыль для axios написал, но не покидает чувство, что такое уже давно есть. Например restful.js, 'Amareis/another-rest-client'

Вот и стало интересно что вообще кто использует.

Так ли страшно использовать 1024 ключ RSA?

В 2 раза легче стало серверу 4096 -> 1024 / 50% -> 25

Так ли страшно использовать 1024 ключ RSA?

Максим Мосейчук, мы вероятно друг друга не слышим. Данные токена JWT изначально открыты. То есть, нет ни малейшего смысла их шифровать - эти данные в токене публичны. Поэтому, именно хэширования(MD5 + secret) вполне достаточно для проверки его целосности/подлинности. Другое дело, что абсолютное большинство библиотек использует именно асимметричное шифрование для этого токена, скорее больше для удобства.

Так ли страшно использовать 1024 ключ RSA?

Я не знаю точно смысла RSA в JWT - так как данные в нем открыты, а подпись используется совсем не для расшифровки данных, а только для проверки "целостности" на случай подделки данных. В таком случае вполне достаточно хэширования. Но пляска с публичным/приватным ключем подразумевается чуть более секюрной, чем один ключ на всех серверах(как в случае с MD5)

Так ли страшно использовать 1024 ключ RSA?

А это сильная разница для CPU ? 1024 vs 4096 условно в единицах процессорного времени. У меня сейчас 50% процессора занято, а при ключе в 1024 будет на сколько меньше?