The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

OpenNews: Увеличение скорости загрузки Fedora Core 4, opennews (?), 27-Фев-06, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


14. "Увеличение скорости загрузки сервера, на примере Fedora Core 4"  +/
Сообщение от Dimezemail (??), 27-Фев-06, 13:05 
На самом деле, проще всего удалить udev+hotplug и выключить бутсплаш при загрузке, а не менять в корне загрузочные скрипты, ибо потом обновляться крайне сложно будет.
Ответить | Правка | Наверх | Cообщить модератору

17. "Увеличение скорости загрузки сервера, на примере Fedora Core..."  +/
Сообщение от Andrejs Spunitisemail (?), 27-Фев-06, 13:39 
>На самом деле, проще всего удалить udev+hotplug и выключить бутсплаш при загрузке,
>а не менять в корне загрузочные скрипты, ибо потом обновляться крайне
>сложно будет.

В заглавие статьи есть слово СЕРВЕР, ну какие могут быть сложности
с обновлением для сервера, по сути NAT сервера, описанного в статьях
http://www.dzti.edu.lv/isp-serv/index.php

на ISP-serv практически все что активно использвана собрано
своими усилиями, а доступ имеет тоько админ.


В принципе, кто нибудь читал статью, или прочли заголовок,
начали писать коментарии?


Ответить | Правка | Наверх | Cообщить модератору

27. "Увеличение скорости загрузки сервера, на примере Fedora Core..."  +/
Сообщение от Dimezemail (??), 27-Фев-06, 17:44 
Я все статьи прочитал. Т.е. то, что собрал сам, обновлять не надо ни в коем случае? А если дыру найдут?
Ответить | Правка | Наверх | Cообщить модератору

28. "Увеличение скорости загрузки сервера, на примере Fedora Core..."  +/
Сообщение от Andrejs Spunitisemail (?), 27-Фев-06, 18:00 
Если:
дыра в кернеле -- пересобираешь его,
дыра в iptables -- пересобираешь его,
дыра в iproute2 -- пересобираешь его

Как мне кажется большинство дыр, используют тот факт,
что пользователь (которому разрешили доступ в систему)
может выполнить в системе программу, которая повышает
его привелегии. Поскольку в случае рассматриваемого
ISP-serv только у админа есть такой доступ, то подобного
рода дыры можно не учитывать.


Ответить | Правка | Наверх | Cообщить модератору

30. "Увеличение скорости загрузки сервера, на примере Fedora Core..."  +/
Сообщение от Dimezemail (??), 27-Фев-06, 18:22 
Нет.
Дыра в iptables - надо пересобирать iptables+kernel. Читай внимательно свою же статью :)
Правильным выходом было бы заворачивать в пакеты(с написанием spec-файла/Slackbuild/etc), чтобы потом, в случае необходимости, быстро пересобрать. Да и даже на другой машине, т.е. держать компилятор на продакшне - жестоко.
Ответить | Правка | Наверх | Cообщить модератору

33. "Увеличение скорости загрузки сервера, на примере Fedora Core..."  +/
Сообщение от Andrejs Spunitisemail (?), 27-Фев-06, 18:56 
спасибо за поправку, увлекся copy-past:)

в принципе и дыра в iproute2 тоже пересборка ядра, поскольку
esfq патчит и ядро в том числе.

этот вопрос по поводу rpm обсуждался нами, действительно,
сборка производится на другой, более мощной машине,
но я остаюсь сторонником не делать rpm по нескольким причинам
1. менее наглядно виден процесс сборки
2. изложенные шаги в статьях позволят человеку на базе полученных
   знаний самому при желание создавать spec для rpm.
3. в реальной жизни, малый процент тех, кто использует всякие продукшен
   сервера, чаще всего человек имеет полюбившийся ему дистр, его задача
   вывести локалку в интернет (в моем случае общага). Изложенный мною
   материал позволит это сделать практически в любом дистре, а далее
   если он видит необходимость во всяких упомянутых:

- управляемость
- обновляемость (как updates, так и при необходимости -- обычно вследствие прекращения поддержки предыдущего выпуска -- между major releases)
- отчуждаемость и делегируемость управления
- надёжность

пускай сам дорабатывает!


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

По мне чем проще, тем надежнее.

Да и потом посмотрите на патчи, их авторы не пишут всяких rpm,
они полагают что это не их забота. Точно так поступил и я.

Если кто то заинтересовался переколбасить изложенный мной на
http://www.dzti.edu.lv/isp-serv/index.php
материал, как это подабает в rpm или что либо ещё, то ради бога!

дело в том, что  прежде чем создавать rpm нужно знать что ты
хочешь и как это реализовать без всяких наворотов.

Реализация без наворотов и предлагается мною.

ЗЫ
Одной статьей нельзя убить всех зайцев, мое мнение такое:
в статьях излагается основной практический подход и основная идеология,
а остальное пускай сами заинтересованные админы дорабатывают.

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


Ответить | Правка | Наверх | Cообщить модератору

45. ":)"  +/
Сообщение от Michael Shigorinemail (?), 28-Фев-06, 12:34 
>но я остаюсь сторонником не делать rpm по нескольким причинам
>1. менее наглядно виден процесс сборки
Эт на первых порах, сам тоже дооолго боялся -- спасибо доброму Vladimir Bormotov, терпеливо отучал от пакетофобии новичков вроде меня в fido7.ru.linux :-)

>2. изложенные шаги в статьях позволят человеку на базе полученных
>   знаний самому при желание создавать spec для rpm.
Эт да.

>3. в реальной жизни, малый процент тех, кто использует всякие продукшен    сервера
Ну вообще-то production -- это "производство", т.е. production server == "боевой сервер".  Вне зависимости от того, как он создан и что внутри, если используется для работы, а не тестов или так, поиграться в серверы науки ради -- то такой и есть.


>Да и потом посмотрите на патчи, их авторы не пишут всяких rpm,
>они полагают что это не их забота. Точно так поступил и я.
Не стоит расписываться за всех, это не так.


>дело в том, что  прежде чем создавать rpm нужно знать что
>ты хочешь и как это реализовать без всяких наворотов.
>Реализация без наворотов и предлагается мною.

А я говорю, куда _дальше_ думать помогает :-)

>ЗЫ
>Одной статьей нельзя убить всех зайцев, мое мнение такое:
>в статьях излагается основной практический подход и основная идеология,
>а остальное пускай сами заинтересованные админы дорабатывают.

Андрей, да спасибо же :-)

Ответить | Правка | Наверх | Cообщить модератору

44. "пакеты для дебардакизации"  +/
Сообщение от Michael Shigorinemail (?), 28-Фев-06, 12:23 
>Нет.
>Дыра в iptables - надо пересобирать iptables+kernel. Читай внимательно свою же статью
>:)

Ну это если patch-o-matic баловаться, то практически обязательно :-(

>Правильным выходом было бы заворачивать в пакеты(с написанием spec-файла/Slackbuild/etc), чтобы потом, в
>случае необходимости, быстро пересобрать. Да и даже на другой машине, т.е.
>держать компилятор на продакшне - жестоко.

Вооот -- видите, всё Вы знаете :-)

Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

46. "пакеты для дебардакизации"  +/
Сообщение от Dimezemail (??), 28-Фев-06, 12:46 
> Вооот -- видите, всё Вы знаете :-)
Я не просто знаю - это единстенный правильный путь, который я советовал автору статьи.
Ответить | Правка | Наверх | Cообщить модератору

43. "router != server"  +/
Сообщение от Michael Shigorinemail (?), 28-Фев-06, 12:21 
>Поскольку в случае рассматриваемого
>ISP-serv только у админа есть такой доступ, то подобного
>рода дыры можно не учитывать.

Для байтогонялки и если игнорировать DoS, которые тоже порой откапывают -- то да; народ когда-то делал рутеры с патчиком к ядру, чтоб не паниковало при отстреле init(8): скрипты настраивают систему и под конец прибивают init, остаётся только ядро.

Но это маршрутизатор, ни разу не сервер.

А для серверов сильно рекомендую linux-vserver.org... (у нас, опять же, поддерживается "из коробки" начиная с Master 2.4)

Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

47. "router != server"  +/
Сообщение от Andrejs Spunitisemail (?), 28-Фев-06, 12:49 
Просто интересно, в приводимых Вами роутеров из коробки можно реализовать

1. идею Layer-7 (фильтрация по контенту, а не по портам) ?
2. ESFQ (справедливое распределение не по сессиям, а IP) ?
3. connbytes (отслеживание сессий передающих большой объем данных) ?


ЗЫ
жду когда Michael Shigorin намылит мне аналог моей статьи, только
тот который читается на курсах, я Вам письмо вчера отправил.

ЗЫЫ
А защита от DoS реализована на уровне ядра, так что особо боятся её не стоит:
http://www.dzti.edu.lv/isp-serv/index.php?l=3#firewall

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру