Спасибо, хорошая обзорная статья, действительно полезная как стартовая точка. Чего как мне кажется не хватает, так это практических примеров. Кроме простого констатирования о сложности генерирования "одноглазого пирата с повязкой и эполетами, держащего в левой руке топор", хотелось бы увидеть как его все же можно получить, используя описываемый инструментарий.
Дорогой тезка, преогромнейшее тебе спасибо! Именно то, что я давно искал среди монструозных комбайнов, но ленился сделать сам. Единственно что могу предложить, это заменить cp на ln, чтобы места лишнего не занимать.
Я правильно понимаю, что любой, кто может отправить на ваш файрвол SYN-пакет с поддельным src IP, эффективно заблокирует вам любой IP, да хоть весь интернет?
В статье перепутана WBT, которая определяется исключительно температурой окружающего воздуха и влажностью, и WBGT из таблички, в которую входит еще и солнечное излучение. WBGT для своего тела можно существенно уменьшить одевшись в белое, или вообще превратить в WBT при помощи зонтика. А WBT никогда не может быть выше температуры окружающего воздуха.
Буферизация прокси-сервера означает, что NGINX сохраняет ответ с сервера во внутренних буферах по мере его поступления и не начинает отправлять данные клиенту до тех пор, пока весь ответ не будет буферизован.
Мне кажется что здесь неправильно описан механизм буферизации. Что интересно, в руководстве администратора NGINX Plus, тоже написано что данные клиенту не передаются до полного вычитывания ответа с апстрима, хотя в основной документации ничего такого нет. Мало того, в описании директивы proxy_busy_buffers_size есть четкое указание на то, что ответ клиенту передается одновременно с получением его от апстрима.
Как-то в порыве быть прогрессивным, и в связи с подошедшим сроком поверки счетчиков поменял все 6 штук на вот такие Элехант. Смотреть все покапзатели практически за раз никуда не залезая конечно прикольно. Вот только первый счетчик перестал подавать признаки жизни через пару недель. Остальные последовали за ним весьма быстро. Первый еще успел заменить по гарантии. К моменту когда я плюнул на все и поменял их на обычные счетчики прошло ~7 месяцев. В живых оставался один счетчик, причем не тот который поменял. Один из сдохших счетчиков разобрал наплевав на гарантию. Батарейка была в порядке.
Те, кто считает что регистратор пытается помочь, пускай и за дорого, клиенту у которого проблема, не обольщайтесь, это не так. Просто какой-то "эффективный менеджер" нашел способ срубить еще немного денежек с клиентов.
У меня на ликвидированной фирме было 3 домена. Причем ООО ликвидировано еще в 2016 году, что не мешало регистрару ежегодно получать деньги с несуществующего ООО. Несколько месяцев назад пришло такое же "письмо счастья". За 2 домена решили заплатить, а один уже и так не использовался, поэтому пусть разделегируется. 2 домена были перенесены на дргугой аккаунт, а тот за который не заплатили так и остался на старом. Никакого разделегирования с ним не произошло. Мало того, я совершенно спокойно оплатил продление этого домена на старом, принадлежащем несуществующему ООО аккаунте.
Попробуйте регистрироваться в хроме в котором отключены все банерорезки.
У меня было то же самое несколько раз с разными картами. В свежепоставленном хроме зарегистрировался с первого раза с данными с которыми до этого не получалось.
Я регулярно, с 9.6 версии, мигрирую пяток проектов, объемы баз 1-7 ТБ. Именно по озвученной схеме. Через три релиза — да, не пробовал, мы мигрируем на каждый новый релиз (не всегда меняя сервер), но я не думаю что возникнут какие-то кардинальные проблемы. В любом случае, всегда есть возможность при каких-то проблемах откатиться на старый сервер. Чудо-утилита с магическим ключиком -k работает очень быстро и не подводила ни разу. Использование pglogical никак не поможет при проблемах c переименованием xlog в wal или необходимостьи переделывать мониторинг.
Не очень понятно, зачем эта морока с одновременным апгрейдом postgres и переездом на новые сервера? Что мешало сначала поднять копию инфраструктуры на той же версии postgres при помощи обычной потоковой репликации, а затем быстренько ее проапгрейдить pg_upgrade?
Уже года как 2 пользуюсь Google Family Link в России, для ограничения использования смартфона и отслеживания перемещейний детей. Никаких проблем с использованием не замечал.
/dev/nvme1 это символьное устройство — контроллер. В свою очередь /dev/nvme1n1 — это уже диск (аналог /dev/sda), а /dev/nvme1n1p1 — это раздел на этом диске (/dev/sda1). Соответственно /dev/nvme1n1p1 будет всегда на /dev/nvme1n1.
А вот почему smartctl выдает что-то осмысленное на /dev/nvme0 как будто это диск, и почему это не совпадает с /dev/nvme0n1 — это вопрос к авторам smartctl видимо.
Спасибо, хорошая обзорная статья, действительно полезная как стартовая точка.
Чего как мне кажется не хватает, так это практических примеров. Кроме простого констатирования о сложности генерирования "одноглазого пирата с повязкой и эполетами, держащего в левой руке топор", хотелось бы увидеть как его все же можно получить, используя описываемый инструментарий.
Дорогой тезка, преогромнейшее тебе спасибо! Именно то, что я давно искал среди монструозных комбайнов, но ленился сделать сам.
Единственно что могу предложить, это заменить cp на ln, чтобы места лишнего не занимать.
Я правильно понимаю, что любой, кто может отправить на ваш файрвол SYN-пакет с поддельным src IP, эффективно заблокирует вам любой IP, да хоть весь интернет?
В статье перепутана WBT, которая определяется исключительно температурой окружающего воздуха и влажностью, и WBGT из таблички, в которую входит еще и солнечное излучение. WBGT для своего тела можно существенно уменьшить одевшись в белое, или вообще превратить в WBT при помощи зонтика. А WBT никогда не может быть выше температуры окружающего воздуха.
Мне кажется что здесь неправильно описан механизм буферизации. Что интересно, в руководстве администратора NGINX Plus, тоже написано что данные клиенту не передаются до полного вычитывания ответа с апстрима, хотя в основной документации ничего такого нет. Мало того, в описании директивы proxy_busy_buffers_size есть четкое указание на то, что ответ клиенту передается одновременно с получением его от апстрима.
Как-то в порыве быть прогрессивным, и в связи с подошедшим сроком поверки счетчиков поменял все 6 штук на вот такие Элехант. Смотреть все покапзатели практически за раз никуда не залезая конечно прикольно. Вот только первый счетчик перестал подавать признаки жизни через пару недель. Остальные последовали за ним весьма быстро. Первый еще успел заменить по гарантии. К моменту когда я плюнул на все и поменял их на обычные счетчики прошло ~7 месяцев. В живых оставался один счетчик, причем не тот который поменял. Один из сдохших счетчиков разобрал наплевав на гарантию. Батарейка была в порядке.
Те, кто считает что регистратор пытается помочь, пускай и за дорого, клиенту у которого проблема, не обольщайтесь, это не так. Просто какой-то "эффективный менеджер" нашел способ срубить еще немного денежек с клиентов.
У меня на ликвидированной фирме было 3 домена. Причем ООО ликвидировано еще в 2016 году, что не мешало регистрару ежегодно получать деньги с несуществующего ООО. Несколько месяцев назад пришло такое же "письмо счастья". За 2 домена решили заплатить, а один уже и так не использовался, поэтому пусть разделегируется. 2 домена были перенесены на дргугой аккаунт, а тот за который не заплатили так и остался на старом. Никакого разделегирования с ним не произошло. Мало того, я совершенно спокойно оплатил продление этого домена на старом, принадлежащем несуществующему ООО аккаунте.
Вобщем вывод один, RUCENTER - жулики.
Попробуйте регистрироваться в хроме в котором отключены все банерорезки.
У меня было то же самое несколько раз с разными картами. В свежепоставленном хроме зарегистрировался с первого раза с данными с которыми до этого не получалось.
Ага, то-то все таксисты ездят на машинах за 2М.
А вот почему smartctl выдает что-то осмысленное на /dev/nvme0 как будто это диск, и почему это не совпадает с /dev/nvme0n1 — это вопрос к авторам smartctl видимо.