Pull to refresh
21
0
Send message

А есть ли какие-либо модели с "удобным" usb портом? Мне например раз 10-20 в день надо жать на юбик 5 нано и хотелось бы не переносить руки сильно далеко

Сейчас пользуюсь KB-G8800 от sven, но там usb порт хоть и встроен в клавиатуру, но расположен так, что к нему все равно приходиться тянуться (дальний правый угол)

Не все сервера действительные?

Тык, почти 10 лет прошло

В статье «Основы Ansible, без которых ваши плейбуки — комок слипшихся макарон» на хабре

У logrotate'а есть параметр olddir и описание задачи выглядит так, как будто стоило использовать его для копирования, а сам logrotate запускать cron'ом

Если предположить что внутри живёт Linux ядро и что dhcp сервер реализован так же как в Linux через открытие raw сокета то все становится очевидно. В Linux тоже не фильтруется трафик, который идёт через raw сокет, потому что подсистема tcp/ip в этом процессе просто не участвует

Последние годы перевожу компании из облаков на свои сервера. Ибо оказывается, что аренда ЦОД, свои сервера и СХД плюс самый быстрый сервис от вендора, софт виртализауии с самой быстрой поддержкой от вендора, ОС, аутсорсинг админов поддержки стоит в 3-5 раз дешевле облаков при расчете на 3/4/5 лет.

Действую подобным образом вы имеете все шансы стать новым облачным провайдером для своих клиентов.
Но при падении — я не знаю провайдеров облачных решений, которые готовы полностью оплачивать ущерб бизнесу из-за отсутствия сервиса. Поэтому и гарантии с облаком — в размере абонплаты.

Так это стандартная практика во всем мире во всех отраслях. Производители серверов сломавшийся сервер вам поменяют, но оплачивать убытки из-за его простоя не будут. Автопроизводители починят сломавшийся автомобиль, но если не будут вам оплачивать упущенную прибыль сорвавшейся сделки, даже если она сорвалась из-за поломки автомобиля и так почти везде.
Если хотите застраховаться от подобных проблем, но стоит обращаться в профильные организации, то есть в страховые компании. Причем если верить гуглу, то даже в России есть облачные провайдеры, которые сотрудничают со страховыми компаниями и вполне могут предоставить подобные услуги. Но нужно понимать что страховая сумма будет всегда ограниченна сверху и напрямую привязана к страховым взносам.
Решается как обычно: «консультантов облака» нужно слушать, а решения принимать самостоятельно, а не «делать все как они рассказывают». В облако есть смысл уносить службы, к которым клиенты через интернет ходят (сайт компании, сервер видеонаблюдения, на котором хранятся видео из филиалов и т.д.). Не стоит переносить в облако ресурсы, если в данный момент основная масса клиентов этого ресурса сидит рядом с сервером, особенно если есть проблема с шириной канала.
Но при этом облако все равно можно использовать для оптимизации вышеуказанных служб.

Например в ваших примерах: основная файлопомойка в офисе, но синхронизируется с облаком в обе стороны. Пока все хорошо, офисные работники работают через быструю локалку с офиснойной копией. Удаленные сотрудники через VPN'ы работают с облачной копией (потому что в облаке интернет шире, чем в офисе). Если в офисе с сервером вдруг что-то случится, то офисные работники перенаправляются в облако, пока все не починят. Да, на время аварии деградирует производительность(из за узкого канала), но уж лучше так, чем «ничего не работает».
С почтой примерно так же поступаем: входящая почта валиться на сервер в облаке, там фильтруется спам, проверяется антивирусом, применяются нужные политики и т.п., а на офисный маилсервер синхронизируются только нужные письма.

Инфраструктура конечно получается сложнее, чем простое «один сервер выполняет одну роль и по ночам бэкапится», в зависимости от конкретного стека и требований возможно что придется пойти на некоторые компромиссы, но обычно оно того стоит если сервисы действительно критичные для компании.
В моем понимании идемпотентность не связана с результатом от слова «никак».
Проведем мысленный эксперимент: пишем генератор случайных чисел на php, выполняем 2 совершенно идентичных GET запроса и получаем разные ответы. Запросы у нас идемпотентные (потому что используют идемпотентный метод GET), а ответы сервера у нас разные.

Второй мысленный эксперимент: отправляем методом POST на форум условный комментарий и получаем в ответ «Ваш комментарий опубликован, через 5 секунд вас автоматически переадресует на страницу обсуждения, если не переадресовало нажмите на ссылку». Потом повторяем этот запрос и получаем точно такой же ответ. В результате мы отправили 2 комментария, использовали не идемпотентный метод POST но при этом получили одинаковые ответы.

То есть идемпотентность в терминологии HTTP это не одинаковость запросов и не одинаковость ответов, это отсутствие намерения клиента своим действием изменить что-либо на стороне сервера (Логи, аналитика и т.д. не в счет, речь о объекте, указанном в URI запроса).
В реальном мире конечно возможно, что где-то вы найдете какую нить ссылку типа example.com/object/delete, при переходе по которой object удалиться, то есть случатся те самые «side effects», но это не сделает данный конкретный GET запрос не идемпотентным, это конкретный программист в конкретном месте нарушил стандарт и поэтому сам себе злобный буратино.
Отнюдь. Запрос с отбрасыванием реферера никак нельзя считать идемпотентным.
«идемпотентность» это не возможность сказать «точно такой же» с умным видом. В контексте нашего разговора смысл слова «идемпотентность» отличается от изначального. Идемпотентность это свойство метода, а не всего запроса. Именно это сказано в 9.1.2 все того же rfc2616 и в 4.2.2 rfc7231, а в 8.1.3 rfc7231 даже есть таблица, и в ней методы DELETE, GET, HEAD, OPTIONS, PUT и TRACE обозначены как идемпотентные, а CONNECT и POST нет.
В вышеназванных документах пару раз встречается словосочетание «idempotent request», но в моем понимании это «запрос, использующий идемпотентный метод», а не «запрос неотличимый от другого», на это намекает хотя бы то, что речь идет о запросе в единственном числе.

Ну и там же об автоматизации перезапросов:
Вы трактуете «SHOULD NOT» слишком строго, как будто там написано «MUST NOT». В rfc2119 (на который есть ссылка 1.2 rfc2616 и 1.1 rfc7231) сказано:
4. SHOULD NOT This phrase, or the phrase «NOT RECOMMENDED» mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

Резюмируя
То есть в сухой выжимке — браузер (самостоятельно) может выполнить:
— максимум два запроса;
— эти запросы должны быть абсолютно идентичны.

— Да, максимум 2 запроса, но если сильно хочется, то ладно уж, делайте сколько хотите, стандарт позволяет.
— абсолютная идентичность запросов не требуется стандартом, требуется идемпотентность используемых в запросе методов.
Я тут полистал rfc2616 (HTTP/1.1) и на мой скромный взгляд действие браузера выглядит вполне логично.

Во первых в разделе 8.1.4 rfc2616 написанно:

8.1.4 Practical Considerations

Client software SHOULD reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request sequence is idempotent (see section 9.1.2).
...

А во вторых в том же разделе 8.1.4:

Servers SHOULD always respond to at least one request per connection, if at all possible.
...


То есть повтор браузером идемпотентных запросов — это именно то, что рекомендует стандарт и именно это поведение для браузеров выглядит логичным. При этом использование 444 кода в nginx в некоторых случаях (конфиг из статьи, первый запрос мы делаем сразу на локейшен, прикрытый 444) может быть нарушением стандарта, поскольку в этом случае nginx закроет tcp-соединение до того, как даст первый ответ (а может и не быть нарушением стандарта, если браузер использует Keep-Alive соединение и недавно делал запрос в другим локейшенам).

Зы честно говоря раньше я думал что nginx «забывает» соединение (примерно как DROP в iptables), но оказывается что он не «забывает» соединение, а корректно закрывает его отправляя FIN браузеру, дожидается от него FIN, и подтверждает его(если задуматься, то это тоже логично, ведь tcp управляется ядром, а не самим nginx'ом). То есть использовать код 444 для борьбы с условным DDOS'ом не так выгодно, как использовать тот же DROP в iptables (при использовании DROP в iptables мы просто выкидываем входящий пакет и ничего не отправляем в ответ, в случае же 444 мы сначала вынуждены правильно установить tcp-соединение, а потом корректно его завершить). Но при этом анализировать http-трафик «конфигом» nginx намного удобнее, чем делать тоже самое «конфигом iptables» (или любого другого фаервола), поэтому вполне логично при DDOS'ах и прочей нехорошей активности ботов собирать их адреса с помощью 444, а потом выбирать эти адреса из лога nginx и банить их в том же iptables (через ipset если их много). Дамп трафика в формате wireshark можно посмотреть тут

Зыы все тот же rfc2616 не требует передачу реферала. Передача этого заголовка прямо запрещена при переходе с https ресурса на http, но нигде не сказано что в других случаях этот заголовок обязателен, а например в 15.1.2 написанно

We suggest, though do not require, that a convenient toggle interface be provided for the user to enable or disable the sending of From and Referer information.
...
Но видимо разработчики браузеров считают что иногда можно и «просто так» удалить этот заголовок, видимо пытаясь решить какие-то возможные зацикливания на стороне неадекватно-ведущего (с точки зрения стандарта) себя сервера. Хотя нельзя и исключать того, что это баг, а не фича браузеров.
иногда «комментарий» — это не высказывание противоположной точки зрения, а просто дополнение на заданную и смежные темы.
У меня нет магического шара, который позволял бы видеть будущее, но есть куча инструментов позволяющих помнить прошлое.
Если где-то в прошлом я нашел какую-то ссылку и запомнил ее, а сейчас перехожу по ней и там нет того документа, который я ожидал увидеть, то я предпочту получить внятную информацию о том, что именно случилось: это я ссылку неправильно запомнил и документ действительно был тут раньше но теперь удален.

Есть стандарт, в котором про 410 код написано следующее:
10.4.11 410 Gone
The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. Clients with link editing capabilities SHOULD delete references to the Request-URI after user approval. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead. This response is cacheable unless indicated otherwise.

The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's site. It is not necessary to mark all permanently unavailable resources as «gone» or to keep the mark for any length of time — that is left to the discretion of the server owner.

Вы конечно можете брать эти же самые коды ответа, но интерпретировать их по своему, но особо надеется на то, что вас поймут когда вы отдаете 410 вместо 404 не стоит.
Я требую что бы вы уважали права ботом и не фильтровали доступ к вашим сайтам из-за того, что боту удобнее посещать curl'ом!
image
410 — раньше тут был документ, но больше его нет и никогда не будет.

404 Not Found[19] — самая распространённая ошибка при пользовании Интернетом, основная причина — ошибка в написании адреса Web-страницы. Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URL. Если серверу известно, что по этому адресу был документ, то ему желательно использовать код 410. Ответ 404 может использоваться вместо 403, если требуется тщательно скрыть от посторонних глаз определённые ресурсы. Появился в HTTP/1.0.

410 Gone — такой ответ сервер посылает, если ресурс раньше был по указанному URL, но был удалён и теперь недоступен. Серверу в этом случае неизвестно и местоположение альтернативного документа (например копии). Если у сервера есть подозрение, что документ в ближайшее время может быть восстановлен, то лучше клиенту передать код 404. Появился в HTTP/1.1.

wikipedia
Разбирал что бы посмотреть на ОЗУ, сгорел какой-то там контроллер, а диск восстановить не получилось никакой магией.

Нее, чудеса конечно бывают, но я в них не верю. Более вероятно что ваш товарищ убил оперативку статикой (это частое явление) или повредил ее механически, а дальше ноут попал в руки не тем специалистам, которые или добили его (уронив пару раз по дороге) или поменяли планку памяти и присвоили его себе сказав вам что ничего восстановить нельзя.

Ну или последний и наиболее вероятный вариант на мой взгляд: с того момента как история случилась, до того момента как вы ее изложили в комментарии выше из нее потерялись какие-то важные детали (или наоборот появились лишние). Вполне вероятно это могло случится еще на этапе «товарищ пересказывал вам как именно дело было».
позанудствоваю немного: sata-диск действительно можно отключать\подключать на горячую, физически диск и материнки (или контроллеры) к этому готовы (во всяком случае должны быть). Готово ли к этому ПО зависит от того, в какой режим выставлен режим совместимости SATA в биосе (или UEFI). Как правило есть 2 варианта: IDE — режим совместимости, нужен только для установки старых ОС и AHCI — новый режим, именно он поддерживает горячую замену, но в могут не работать некоторые старые ОС (тут под старыми имеется ввиду что-то типа Windows до XP и прочие досы с полуосями).

Справедливости ради стоит заметить что начиная с появления Windows Vista некоторые производители ноутбуков стали убирать из тогдашних биосов эту настройку (тогда все говорили что это MS пытается бороться с установкой WinXP на новые ноутбуки и мотивирует всех висту использовать).
Как дела на декстопах обстоят честно говоря не скажу, на серверах обычно просто: на старых моделях по умолчанию IDE, на новых AHCI выставлено. Поэтому если арендуете какую-то железку, особенно если используете софт-рейд (mdadm) то стоит перед вводом в эксплуатацию проверить текущий режим и в случае необходимости переключить его в AHCI. В противном случае для замены диска придется согласовывать даунтайм (проверить можно в dmesg например).

И раз зашла про это речь, то стоит упомянуть что если изменить данную настройку, то винда перестает грузиться, требуется ресетап или шаманство с драйверами установленной винды.

Извлечение диска в линуксе в режиме AHCI:
  • Находим диск физически, что бы понимать какой именно мы будем извлекать (по серийникам, по индикации бэкплейна или еще как-то)
  • Перестаем использовать диск (отмонтируем ФС, переносим на другой PV наш LV если речь про LVM и т.д. Зависит от того, как у нас диск используется)
  • echo 1 >/sys/block/sdX/device/delete
    Вместо sdX указываем правильный диск.
  • Вытаскиваем диск физически (если нет бэкплейна, то рекомендуется сначала отключать питание, а потом дата-кабель. После отключение питания желательно подождать несколько секунд что бы головки успели запарковаться на штатное место)

Установка нового диска:
  • Подключаем диск (если нет бэкплейна, то рекомендуется сначала подключать дата-кабель, а потом питание)
  • echo "- - -" >/sys/class/scsi_host/hostX/scan
    hostX заменяем на номер шины с диском (host0, host1 и т.д.… если не знаете можно перебрать все имеющиеся в ОС)
Если бы у мобильного приложения хабры UI вменяемый был бы, то я бы еще и комментарием в правильную ветку наверное попал бы :-)

А статья у нас не об особенностях работы 444, а о том, что для автора оказалось неожиданным поведение браузеров. Я бы переформулировал вывод в примерно такое: не используйте 444 в nginx для ответа реальным пользователям, даже если вам нечего им ответить. Пользователю лучше отдать 403, 404 или другой подходящий по смыслу код. 444 придумали для борьбы с «плохими» ботами и применять его нужно только после взвешивания всех «за» и «против», и желательно как временную меру (то есть например собирать 444 из лога и банить этих ботов в фаерволе или что-то типа того).

418 "лучше" чем 444. 418 дойдет до браузера, отличить же 444 от "ошибки сети" (с точки зрения браузера) невозможно

От ПО и его настроек зависит. В том же фронтоле (на него шикарная документация лежит прям на офф. сайте, в отличии от конкурентов, что позволяет освежить такие моменты в памяти) это реализуется через «разрезы», как это называлось в 1с я сходу не вспомню, да и честно говоря даже не уверен что это был базовый функционал, а не доработка нашего программиста.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Registered
Activity