Хорошим тоном в профессиональной среде считается плюнуть в сторону howtoforge. Точнее в «мастеров по бесмысленному применению» чужих мыслей на счет тонкой (и толстой) настройки сервера. Вот допустим, есть тысячи кратких мануалов о том, как настроить nginx, установить proxmox и т.д. По сему стоит мой «саморучно» установленный proxmox, c sysctl «из коробки» debian, с параметрами на хостовой машине виртуализации типа такого:
net.core.netdev_max_backlog = 1000
И кучка гостевых машин с их параметрами:
net.core.netdev_max_backlog = 100500
Чую сердцем, это похоже на чувака с горлом шириной в арбуз и ртом — в мышиный сфинктор. При этом поди поищи верный net.core.netdev_max_backlog в интернет — найдешь советы выставить этот параметр в 30000. ОК, только в оригинале той тиражируемой рекомендации рассматривалась машина с аплинком в 10Gb и железяка HiEnd класса (но какое нам дело).
И немного ворчания на эту тему:
Ладно, тут вроде бы можно догадаться, но о чем я совершенно боюсь не догадаться и страстно хочу подергать — параметры вида:
kernel.*
vm.*
fs.*
debug.*
dev.*
ubc.*
net.* (с этого и начну)
abi.*
crypto.*
sunrpc.*
А может в дефолтном какие параметры отсутствую начисто? Может есть какой-то дотошный гайд «для задумывающихся» с примерами из 2011/12 года?
Ман — это не совсем тот вариант, в сорцы ядра погрузиться — не хватит мозгов. Чего делать? Тупо отвалить от ядра на год-другой?
Для затравки, была всего пара статей на хабре по защите от спуфинга без всяких предупреждений, что
включенный *.rp_filter поставит вас боком, если у вас «размазанный» кластер железяк (есть деньги на кластер — купи услуги админа).
Чем чреват *.accept_source_route? Сам accept_source_route упомянут в гугле (за прошедший год) всего 3 тысячи раз. Это как бы намекает на дефицит знаний на эту тему («сиськи» обсуждали 3,4 млн раз за этот год — это в 1150 раз чаще).
