Прям так уж никогда не приходилось расковыривать баги в коде, которые совсем не очевидны ни тебе, ни исходному автору кода? Мне вот точно также даже при наличии кода приходится на админской позиции разбираться с косяками приложения, потом объяснять разработчику косяки в его реализации и заставлять править.
И кстати со стороны вендора тоже приходилось работать. Столько кейсов бывает "у вас всё работает неправильно", а доказать, что это так, почему-то не могут, просто "я так чувствую". Поэтому да, нужны доказательства и нормальное описание стенда, в том числе и для того, чтобы вендор мог воспроизвести ситуацию и проверить, а не вот это вот "детальное описание бага и стенда я вам не дам, воспроизводите как-нибудь сами".
А уж проприетарность/открытость продукта может вообще никак не влиять на качество документации. Сколько раз встречал открытый код с отвратительной документацией, которая еще и оказывается неактуальной или вообще путающей, потому что описывает совсем не то, как работает код сейчас. При этом код еще и страшнющий, который лучше бы вообще никогда не видеть.
proxy_pass https://api.telegram.org/;
А резолвинг-то, наверное, все еще идет только при старте или релоаде nginx'а? Т.е. если вдруг поменяется IP, то все встанет?
Во-первых, что это за таинственные «некоторые» гипервизоры, у которых нет функции выключения VM?
Имхо, тут вопрос не в «нет функции выключения», а то, что корректный фенсинг — это жесткое отключение из розетки (если проводить аналогию с железками), а не милая просьба «выключись, пожалуйста». И вот если хост не смог выключить быстро VM (ну зависли там процессы напрочь и система не хочет выключиться), то в зависимости от критичности кластеризованного сервиса может быть придется и весь хост погасить.
Если клиенты довольны и угрозы безопасности нет, то в чём дело?
Клиент не понимает, что он делает/получает, поэтому он и доволен.
В крупном банке на любые операции с правами администратора будете год получать разрешение от всех отделов безопасности по цепочке.
А если не пошли и не получили разрешения, то получать по шапке позже, когда все эти отделы выяснят, что что-то тут сделано без их разрешения.
Да и не нужны админские права для генерации ключа в большинстве случаев.
Еще раз — есть корректный способ (генерация ключа у клиента); есть не очень корректный (генерим сами). Тот, кто будет читать эту статью должен сам решать, как же ему делать. И это стоило отобразить в статье
появились клиенты, для которых нельзя применять OpenVPN (политики безопасности, нежелания и.д.),
Если у клиента такая политика безопасности, то маловероятно, что им подойдет вариант, когда их ключ у кого-то еще есть.
Мне самому в свое время пришлось разбираться с похожей схемой с авторизацией по ключам. И junior-админу предыдущими админами просто была вручена инструкция «генеришь ключ, отдаешь клиенту». И тут вдруг банк сказал «ключ генерим мы сами», и у этого junior'а внезапно все встало.
Ну и еще если вдруг что-то сломается, клиент всегда может сказать «ну и что что моя запись в логах, ключ-то у вас, вы сами все и сломали».
Выдать пользователю инструкцию по генерации ключа и отсылке вам запроса не всегда возможно — слишком сложные действия на которые у пользователя может не быть прав.
Если нет прав, значит у пользователя есть админы. Раз есть админы, значит они должны знать, что у пользователя есть какая-то кастомная схема с авторизацией по ключам. Потому что когда у пользователя что-то сломается, он пойдет к своим админам в первую очередь, а тем придется ковыряться по всей цепочке.
PSS: JIRA есть СОО (BTS) – Система Отслеживания Ошибок (bug tracking system), а не система отслеживания инцидентов. BTS нужна для ЖЦ объекта во время «Разработка» (Development), а не «Сопровождение» (Maintenance).…
С обывательской, это как забивать гвозди микроскопом, потому что он тяжёлый и, таки, забивает
Мёсье потрудился посмотреть JIRA и выяснить, что в ней довольно-таки много различных доп.модулей, которые делают из JIRA почти всё, что угодно?
Там, скорее, Commonwealth. По моим субъективным ощущениям, там и австралийский акцент был.
На подготовке к экзамену мне говорили, что там может быть куча всяких разных акцентов. Да и в тестовых IELTS были куча разных ужасных акцентов.
Я свои мысли по теме высказал за минуту-полторы, жду вопросов
Ну так во всех описаниях, примерах, на подготовке говорят, что нужно говорить столько, сколько задано. Поэтому и дают вначале время для подготовки, чтобы приблизительно прикинуть, сколько и чего говорить
Все зависит от конкретного человека. Можно и за месяц подготовиться, но должен быть нормальный уровень. Во-первых, найдите примеры тестов и попробуйте их написать — поймете, как у вас с подготовкой, хватает ли аудиокниг для listening. Во-вторых, нужно все равно найти, с кем говорить, благо интернеты сейчас есть, найти собеседника не проблема
Вот ведь в чем загвоздка. Не нравится — не включай. Никто не заставляет им пользоваться — это же не единственный режим.
Лично у меня умный будильник прекрасно работал (и судя по интернету много у кого тоже), но теперь его нет
Права доступа на запись настроены, но CMS хочет как минимум /cache и /administrator/cache на запись — скрипты не растерялись — теперь там создаются :)
Да пусть сколько угодно создаются — зачем разрешать выполнение php в кэше?
https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/, см раздел 'Passing Uncontrolled Requests to PHP'
Про вложенные группы читайте внимательно релизноты и описание тикета — там не всегда все очевидно. Например, узел может быть в подгруппе, но не быть в общей группе
> приведя к закрытию мостов, задержке или отмене железнодорожных и авиарейсов.
> четвёртом по размеру шотландском городе Данди частично было отключено энергоснабжение,
У меня создается впечатление, что не энергии было много, а потребления было меньше в этот день
Alt'ом много где вызывается меню, так что не вариант. Вводить заглавные аббревиатуры лично мне приходится крайне редко, и на этот случай можно как раз включить CAPS другим сочетанием (на Linux, например, у меня для этого используется Shift+CAPS). Хотя я, кажется, набираю их все равно с Shift'ом
Прям так уж никогда не приходилось расковыривать баги в коде, которые совсем не очевидны ни тебе, ни исходному автору кода? Мне вот точно также даже при наличии кода приходится на админской позиции разбираться с косяками приложения, потом объяснять разработчику косяки в его реализации и заставлять править.
И кстати со стороны вендора тоже приходилось работать. Столько кейсов бывает "у вас всё работает неправильно", а доказать, что это так, почему-то не могут, просто "я так чувствую". Поэтому да, нужны доказательства и нормальное описание стенда, в том числе и для того, чтобы вендор мог воспроизвести ситуацию и проверить, а не вот это вот "детальное описание бага и стенда я вам не дам, воспроизводите как-нибудь сами".
А уж проприетарность/открытость продукта может вообще никак не влиять на качество документации. Сколько раз встречал открытый код с отвратительной документацией, которая еще и оказывается неактуальной или вообще путающей, потому что описывает совсем не то, как работает код сейчас. При этом код еще и страшнющий, который лучше бы вообще никогда не видеть.
Хотя если смотреть прямо в доках, то вроде как завязываться на переменную уже не обязательно.
proxy_pass https://api.telegram.org/;А резолвинг-то, наверное, все еще идет только при старте или релоаде nginx'а? Т.е. если вдруг поменяется IP, то все встанет?
Имхо, тут вопрос не в «нет функции выключения», а то, что корректный фенсинг — это жесткое отключение из розетки (если проводить аналогию с железками), а не милая просьба «выключись, пожалуйста». И вот если хост не смог выключить быстро VM (ну зависли там процессы напрочь и система не хочет выключиться), то в зависимости от критичности кластеризованного сервиса может быть придется и весь хост погасить.
А если не пошли и не получили разрешения, то получать по шапке позже, когда все эти отделы выяснят, что что-то тут сделано без их разрешения.
Да и не нужны админские права для генерации ключа в большинстве случаев.
Еще раз — есть корректный способ (генерация ключа у клиента); есть не очень корректный (генерим сами). Тот, кто будет читать эту статью должен сам решать, как же ему делать. И это стоило отобразить в статье
Если у клиента такая политика безопасности, то маловероятно, что им подойдет вариант, когда их ключ у кого-то еще есть.
Мне самому в свое время пришлось разбираться с похожей схемой с авторизацией по ключам. И junior-админу предыдущими админами просто была вручена инструкция «генеришь ключ, отдаешь клиенту». И тут вдруг банк сказал «ключ генерим мы сами», и у этого junior'а внезапно все встало.
Ну и еще если вдруг что-то сломается, клиент всегда может сказать «ну и что что моя запись в логах, ключ-то у вас, вы сами все и сломали».
Если нет прав, значит у пользователя есть админы. Раз есть админы, значит они должны знать, что у пользователя есть какая-то кастомная схема с авторизацией по ключам. Потому что когда у пользователя что-то сломается, он пойдет к своим админам в первую очередь, а тем придется ковыряться по всей цепочке.
Почему из мануала в мануал тянется генерация закрытого ключа клиента? Этот ключ должен быть только у клиента и никого более.
Уже много раз писали (и на хабре тоже): не суйте в пхп все подряд
На подготовке к экзамену мне говорили, что там может быть куча всяких разных акцентов. Да и в тестовых IELTS были куча разных ужасных акцентов.
Ну так во всех описаниях, примерах, на подготовке говорят, что нужно говорить столько, сколько задано. Поэтому и дают вначале время для подготовки, чтобы приблизительно прикинуть, сколько и чего говорить
Лично у меня умный будильник прекрасно работал (и судя по интернету много у кого тоже), но теперь его нет
https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/, см раздел 'Passing Uncontrolled Requests to PHP'
Правда -h в sort'е появился относительно недавно.
> четвёртом по размеру шотландском городе Данди частично было отключено энергоснабжение,
У меня создается впечатление, что не энергии было много, а потребления было меньше в этот день