• Как работает Stack Overflow — железо
    –1
    >В даннй момент у нас примерно 2 ТБ данных в SQL (1.06/1.16 ТБ на первом кластере из 18 SSD и 0.889/1.45 ТБ на втором, состоящем из 4 SSD). Возможно, стоило бы задуматься об облаках, но сейчас мы используем SSD и время записи в базу равно буквально 0 миллисекундам

    Возможно уже давно пора было задуматься о переносе базы с локальных винтов на внешнюю SAN хранилку, не?
  • Обновите свою прошивку iLO
    –1
    CCЗБ же — менеджмент сетку в интернеты шарить без впн.
  • Мигрируем на Chef Server 11
    –2
    Ubuntu12.04. Oh, God, why…

    Ну это шутка юмора, а вопрос все же висит: собственно говоря, во что на 10-ке у вас утыкалась производительность? Исключительно памяти не хватало? Просто довольно интересно, на таком не маленьком сете серверов где происходит затык.

    Вообще ситуация выглядит странно: что-то не работает — а давайте обновимся до последней версии, не по красноглазому, что-ли.
  • FQ_CoDel — планировщик пакетов, который сделает все за вас
    0
    > С использованием pfifo_fast пинг при забитом канале повышается до 8мс.
    Вы так говорите, будто это серьезный показатель хорошей работы.

    + необходимость своего шейпера без BQL, как бы намекает на отсутствие нормальной борьбы с TCP синхронизацией?
  • Переход с HP EVA на 3PAR StoreServ 7400. Реальный опыт внедрения
    0
    Вообще мне нравиться raid5 в его реализации на 3par. Диски бьются на гиговые чанклетсы, собираются в группы + данные мажуться по всей группе чанклетсов мелкими блоками. Таким образом ребилд так нелюбимой вам пятерки проходит в считаные минуты.

    Мне не нравятся оговорки «если важна скорость и надежность». Вы когда-нибудь встречали кастомера, которого волновали бы только скорость и надежность? Если да — 10-ку ему в плечи и не нужно ни 5-ки ни 6-ки ни прочих извратов. Всегда есть вопрос, что же важнее. И пока все конторы в которых я проводил инсталяции выбирали небольшой прирост производительности в угоду не очевидному выигрышу в надежности.
  • Переход с HP EVA на 3PAR StoreServ 7400. Реальный опыт внедрения
    0
    Как мне нравятся такие советчики. Почему? Что за бред с 50-м рейдом. Ладно, допустим, вы являетесь фанатом NetAPP и будите доказывать с пеной у рта, что 5-й рейд небезопасен и его нельзя использовать в продуктиве. Не хочу влазить в холивар. Но 50-й то рейд в таком случае зачем? и нафига 60-й?

    P.S. мне действительно интересно, кто это использует.
  • Переход с HP EVA на 3PAR StoreServ 7400. Реальный опыт внедрения
    0
    Простите, а какой лучший выбор на больших объемах?
  • Распределенная брутфорс-атака на CMS с точки зрения хостера
    +1
    Ох уж эти обезличенные графики. Ордината в килограммах или в локтях?
  • БИНС-шминс. Вводная статья
    +2
    Сложилось впечатление, что кто-то нашел методичку и сделал выдержку оттуда, изредка заменяя предложения, чтобы вроде как не просто скопипастить.
    У нас так обычно лабы сдавались на младших курсах.
  • Честный жребий
    +1
    Ох уж эти ленивые, хитрые, недоверчивые и охочие до выпивки друзья, способные в уме вычислять однонаправленные хеши.

    P.S. Спасибо за интересные замечания.
  • Честный жребий
    0
    В плане сложности алгоритма — если использовать алгоритм с шифрованием голоса каждого участника то получаем N вычислений
    Если использовать конкатенацию + hash на этапе вычисления результатов — это те же самые N вычислений хэша, но при этом мы не решаем проблему, если последним голосует заговорщик — ему всего-лишь нужно будет в онлайне просчитывать хэши а не суммы или xor-ы
  • Честный жребий
    0
    Ну если абстрагироваться от конкретной ситуации — если известен алгоритм расчета значений — просчитать результат не проблема. Если алгоритм неизвестен, то рано или поздно он станет известен :)

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

    В варианте, который я предложил, даже если 3 из 4 человек участвуют в сговоре, они не могут предугадать, что конкретно загадает жертва + секрет не зависит от вариантов алгоритма подсчета.

    Этот алгоритм конечно не защищен с точки зрения отрицания(можно конечно добавить неотрицаемые подписи), но для данной задачи это не принципиально.
  • Честный жребий
    +2
    По дороге домой размышлял, каким бы образом я пытался мухлевать в данной ситуации и таки придумал, что можно сделать.
    Если Алиса состоит в сговоре с кем-то, то она может либо вбить число состоящее из одних только нулей и таким образом отказаться от своего голоса, либо сообщить последнему голосующему свое число(по сути то же самое, но на одну операцию вычисления больше).
    В чистом остатке — Алиса + последний голосующий решают кого отправить в поход. Стойкость алгоритма должна гарантироваться невозможностью менять результат в процессе объявления.
  • Честный жребий
    0
    Да, посыпаю голову пеплом, в вашем алгоритме хеш считается только один раз, хотя меня и смущает доверие одному человеку функции держателя секрета (то-есть когда от его данных зависит результат).
  • Честный жребий
    +1
    А по сути своей не важно как будет выбираться ЗНАЧАЩЕЕ число(то которое будет складываться в общую сумму). Ведь мы же не будем знать такие числа для других участников голосования. Его достоверность мы в конце просто проверим сложив с солью и применив к ним ключ — на выходе должны получить заявленный в начале hash.
    Ну а сумма рандомных чисел от каждого участника — есть величина случайная(если не брать во внимание возможность любимых чисел и прочих индивидуальных особенностей).
  • Честный жребий
    +1
    UPD — для решения исходной задачи — делаем то же самое, но пишем вместо имени избранника рандомное число. В конце считаем что-то наподобие div 4 от суммы всех чисел и отправляем участника под сим гордым номером за пивом.
  • Честный жребий
    +1
    Ах боже мой, прошу прощения — в пылу сражений я неверно осознал для себя задачу и предложил решение для честного открытого голосования. для отправки гонца.

    По сей причине приношу свои извинения.

    По сути своей я просто предложил публичную проверку по примеру авторизации в Unix.
  • Честный жребий
    0
    Вобщем-то показанный алгоритм не соответствует решаемой задаче. (Насколько я понимаю это алгоритм Честных выборов Меррита). В той же прикладной криптографии есть алгоритм честного бросания монетки, и в данном конкретном случае, вполне себе достаточно обобщить его на количество участников > 2.

    Например так:
    Каждый участник голосования пишет имя, добавляет к нему рандомную строку. Шифрует произвольным ключом.
    Показывает всем хеш и рандомную строку.
    После того, как все показали свою значения hash + Random — можно публично оглашать результаты + в подтверждение показывать свой ключ для проверки.

    В данном конкретном случае такой алгоритм позволит уберечься от каких-то лишних телодвижений.

  • Дон Джонс. «Создание унифицированной системы IT-мониторинга в вашем окружении» Глава1.Управление вашим IT окружением: четыре вещи, которые вы делаете неправильно
    0
    Прошу прощения, если я настолько косноязычен, что не смог донести свою мысль касательно п.3. «Вы измеряете не то и не там.»

    Лично мое мнение — технарь должен считать свои метрики, исходя из которых он может плясать — например загрузка цпу, время выполнения дисковых операций, да пусть это даже будет энергопотребление в датацентре. Но это никак не время доступности системы, TCO и прочие вещи, необходимые для бизнеса. В моем понимании эти метрики позволяют оценить работу этого технаря и поэтому у него не должно быть возможности ими манипулировать + собственно говоря это задача его менеджера — предоставлять подобную статистику не вникая в технические детали.
  • Дон Джонс. «Создание унифицированной системы IT-мониторинга в вашем окружении» Глава1.Управление вашим IT окружением: четыре вещи, которые вы делаете неправильно
    0
    Прошу прощения, но первая мысль, которая возникает при прочтении названия — «Да пошел бы ты №$%^ !»

    После прочтения всего перевода — едкое чувство недовольства и несогласия. Итак:
    п.1 — Лично я считаю, что инструменты должны быть удобными, и если мне удобно юзать какти в одном месте, а nagios в другом, я вероятнее всего так и сделаю и мне будет начхать, на то, что это не вписывается в чью-то общую картину мира.
    п.2 — Я вообще не понял, если кто-то не в состоянии описать проблему в email, то навряд ли он сделает это лучше в баг/таск трекере.
    п.3 — После «бездействие в подстраивании технологии под нужды бизнеса» дальше вообще не читал. Тут вообще, по сути своей ошибка — какого черта технари должны считать метрики бизнеса? Особенно если учитывать, что на этих метриках считается продуктивность этих же технарей.

    В общем сама по себе тема интересна, но вот мысли автора меня несколько смущают.

    P.S. Переводчику огромное спасибо, прочиталось довольно легко. Жду следующие главы, чтобы можно было дальше злиться и не соглашаться.
  • Статистика отказов в серверной памяти
    –2
    Если кто-то прочитал ссылки — там идет исследование «consumer-серии железа».
    На фотке я так же вижу кусок несерверного железа. Так о каком ECC сейчас речь? О какой статистике по винтам, если это SATA? Саташные винты вообще не рекомендуются к использованию в production.

    Мой совет: s/сервер/pc + не делать таких глобальных выводов основываясь на данных которым больше 3/5 лет
  • Лучшие компьютерные игры всех времен и народов по версии хабрасообщества 2013 года
    +32
    Ну а как же Сапер?
    image
  • AXFR — возвращение
    0
    > Но если DNS-сервер сконфигурирован неверно, любой юзер может получить доступ к этим данным.

    Я думаю, что это основная мысль поста. Все! Больше ничего не надо. Админ разрешил трансферить зону кому попало — это его проблема.

    Это то же самое, что давать root access на любой публичный ip с паролем qwerty.
  • Сборник полезных ссылок для системного администратора
    0
    jreypo.wordpress.com — Неплохая подборка статей на тему unix(hp-ux в основном) и виртуализации.
    omasse.blogspot.com — Technical blog about HP-UX, VMware ESX, SANs, Blade Servers and other similar subjects.
    communities.vmware.com/community/vmtn — VMTN – VMware Technology Network
    anticisco.ru — Годный ресурс по цискам.
    scribd.com — Онлайн хранилище документов(довольно часто можно найти готовые решения или уже созданную документуху)

    tools.ietf.org — Коллекция rfc + много чего еще
    ripe.net — Думаю в пояснениях не нуждается
  • А как Вы передаете клиентам логины/пароли?
    0
    Если кастомер адекватен и умеет пользоваться цифровыми ключам — шифрованное письмо с цифровой же подписью
  • Уязвимость нулевого дня в роутерах Cisco Linksys
    0
    Я пару лет назад крутил Mikrotik — впечатления не лучшие остались, хотя может быть что-то и изменилось с тех порт.

    А чем вам Lynksys + wrt не нравиться? Мне в плане железа линксисы больше импонируют. С софтом родным у них конечно проблема, особенно если нужно что-то мультикастовое стримить, но tomatousb или wrt решают большую часть проблем(по крайней мере на моем 4200 так и есть).
  • Система мониторинга на BASH
    0
    Одновременное выкачивание скрипта и выполнение его подсетью привидет к а) ботлнеку на сети б) резкому росту нагрузки на железо.

    Мой совет — сразу после удачной сдачи сессии почитайте что такое SNMP. Также я бы посоветовал настроить syslog коллектор + splunk. Если после этого не наиграетесь, попробуйте сделать nagios + centreon + nagvis. После этого — покрутите заббикс, cacti итд. А после этого — идите уже куда-нибудь работать — там получите нормальные таски, которые нужно решать, там и sh прокачаете и bash если захотите, да и perl-а хлебнете.
  • Продвинутая настройка VIM
    0
    Их же там два, либо циркулярка emacs сделала свое дело.
  • Система мониторинга на BASH
    +2
    1 — Система мониторинга на BASH, но через пару абзацев apt-get install perl.
    2 — sudo chmod 777 — вас давно не били?
    3 — «Проект опенсурсный» вы его где-то запаблишили под нормальными лицензиями? Если нет — не тешьте себя призрачными надеждами.
    4 — Откройте же для себя snmp.

    Ну и естественно — зачем же изобретать новый велосипед, если можно погнуть старый? Что принципиально нового дает ваша система? Вы меня не убедили.
  • Создаем Свой Sniffer/FireWall/Parental control/ SpyWare/Клиент для компьютерного Клуба. Технология LSP
    0
    squid + icap же! А для особо упоротых — nprobe + flowtools
  • Хитрости сисадминов
    +1
    Если уж на то пошло, то большинство знакомых мне телекомов замечательно проводят работы в районе 2-6 часов ночи, про дневное время даже речи быть не может. А по поводу пятницы после обеда — это скорее правило любящих побухать эникеев, которым главное с работы свалить пораньше.
  • Хитрости сисадминов
    0
    > USB разъём одинаков по размеру с Eternet разъёмом. Не подключайте вслепую
    Лолшто?
    > Не выполняйте обновлений и критических изменений в пятницу после обеда/
    Почему тег телекомы? Плановые работы как раз и нужно проводить перед выходными, чтобы в случае косяка было время все исправить без истерик.
  • Повышаем безопасность стека web-приложений (виртуализация LAMP, шаг 2/6)
    0
    Аналогично — rhel и CentOS имеют дефолт полиси — DROP(либо же имеют вконце инпута явный дроп.)
  • Повышаем безопасность стека web-приложений (виртуализация LAMP, шаг 2/6)
    0
    1 — А вот это кстати довольно спорный момент — во время работы на одном белорусском сотовом операторе я был вынужден проводить аудит юниксовых серверов. Так вот был там один такой оракловый кластер, к которому кто-то снатил 22 порт. И в итоге раз в минуту туда шел коннект по ssh откуда-то из-за великого китайского файрволла. Я думаю, что никто не застрахован от такой ошибки.
    Или же допустим внутри dmz была сломана машинка на которой крутился VHCS для каких-то там хостинговых целей — если бы не снорт, думаю можно было огрести реальных проблем.

    2 — Из последнего — настраивал я с пол-года назад atlassian стек для одной конторы. Эти продукты использовали mysql. Ставил как было написано в мануале. После завершения инсталяции я там радостно ревоукнул половину прав(вот счас уже и не вспомню, что именно). Ругалась соотвественно только jira, а всякие fisheye, confluence и прочее — радостно продолжили работать. С одной стороны это все черевато проблемами и кучей потраченого времени на тюнинг, но с другой стороны — насколько приятнее на душе, когда ты знаешь, что у тебя все вылизано до предела.

    По поводу лэтенси — сложно сказать для малых баз это может быть безразлично, но на нагруженых — это не так. В любом случае — база должна висеть на быстром диске(очень быстром :) )Навряд ли целесообразно заниматься страйпингом для /var что-то там. Опять же — если это nas, das или еще -то что внешнее — скорее всего есть возможность адаптивной оптимизации либо же снапшотов и прочих вкусностей, что также бывает очень полезно. (ну это уже совсем не безопасность).

    А вообще — нет предела совершенству: Если есть время и есть деньги — виртуалки с разделением по сервисам + dmz с IDS или уже стразу IPS, но это уже совсем другая история, и такие телодвижения требуют значительно больших трудозатрат, чем перенос сервиса на другие порты.

    Для меня было очень познавательным выкидывание виртуальной машинки со снортом в интернет с днс записью admin.xxx.com. Божымой — чего я там насмотрелся.
  • Повышаем безопасность стека web-приложений (виртуализация LAMP, шаг 2/6)
    0
    1 — Ну с одной стороны да — вроде бы перевешивание портов — дело крайне не обязательное, но в плане безопасности все просто:
    В случае каких-то косяков — первым делом ломиться будут по стандартным портам. В купе с логированием трафика — очень просто отследить, кто и откуда ломиться посмотреть нашу базу(пару раз я вылавливал таких интересующихся в совершенно неожиданных местах).

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

    3 — Немного не так — я просмотрел в статье, что настраивается биндинг на ip. Просто к этому я бы еще добавил лог на 127.0.0.1 на необходимый порт, тк правильная ситуация — когда подключение идет с внешнего Ip, а не через шелл на сервере :)

    4 — Грубо говоря да. Тут еще довольно неосвещенный момент — обычно для баз, лично я использую отдельную хранилку, лун, раздел и прочее чтобы разделять I/O системы и базы.

    P.S. Вообще спасибо за проявленный интерес — я думаю, если добавить вышеприведенные ссылки, ваш топик будет крайне содержателен и полезен.
  • Повышаем безопасность стека web-приложений (виртуализация LAMP, шаг 2/6)
    0
    Вообще-то если уж на то пошло, то я бы сделал следующее:

    1 — Перевесить Mysql на другой порт. При этом все, что ломиться на стандартный — в лог iptables.
    2 — Права на БД — сразу минимальные. Потом поднимать в случае возникновения ошибок.
    3 — Убрал бы вообще mysql с 127.0.0.1 — у меня на всех серверах стоит лог+дроп всего, что идет на localhost.
    4 — Ну и да — саму базу я бы перенес на отдельный раздел(проще всего и удобнее всего — симлинком) + изменение имени пользователя.
  • Повышаем безопасность стека web-приложений (виртуализация LAMP, шаг 2/6)
    0
    Ну о какой безопасности можно говорить, если:
    GRANT ALL ON foo.* TO bar@192.168.1.10 IDENTIFIED BY 'mypassword'
  • Балансировка нагрузки между двумя каналами в динамической маршрутизации EIGRP
    0
    А можно нескромный вопрос — почему вы выбрали именно EIGRP?
  • Балансировка нагрузки между двумя каналами в динамической маршрутизации EIGRP
    0
    А можно мне для расширения кругозора уточнить — а на каких более продвинутых уровнях это обсуждается? Просто всегда хотел получить систематизированные и глубокие знания о сетях, но как то не удалось.
    И кстати по поводу CCNA — а насколько глубоко там изучают EIGRP?
  • Балансировка нагрузки между двумя каналами в динамической маршрутизации EIGRP
    0
    Да конечно — это не мой вопрос.

    Прошу прощения, если я грубовато выразился, но я думаю, что статья скорее вредная, чем полезная, т.к. вы показываете дурной пример. По крайней мере вам следовало бы добавить в статью информацию о том, как ПРАВИЛЬНО решить проблему, а не создавать подпорку, которая потом может чем-то аукнуться.