4 Октября 2014 20:15

Freebsd: Король умер, доздравствует король.

Начиная с 1 сентября 2014 года FreeBsd перешло на установку с использованием нового пакетного менеджера (pkg). Любая попытка установки программы из портов выдает следующую ошибку


Код
pkg(8) must be version 1.3.8 or greater, but you have 1.2.7_2.  
You must upgrade the ports-mgmt/pkg port first.

Для того чтобы заработал новый механизм установки программ выполняем следующее:

1. открываем файл /etc/make.conf и дописываем следующую строку
Код
WITH_PKGNG="YES"
Она говорит о том, что мы перешли на установку программ через пакеты.

2. Удаляем существующий конфигурационный файл для pkg и копируем на его место данные из файла по умолчанию
Код
# rm -f /usr/local/etc/pkg.conf
# cp /usr/local/etc/pkg.conf.sample /usr/local/etc/pkg.conf
3. Создаем каталог /usr/local/etc/pkg/repos
Код
# mkdir -p /usr/local/etc/pkg/repos

4. Создаем в этом каталоге файл FreeBSD.conf со следующим содержимым
Код
FreeBSD: { 
 url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest",  
 mirror_type: "srv",  
 enabled: yes 
}
Тем самым мы указали путь на репозиторий.

5. Теперь устанавливаем, если ранее не было установлено, новый установщик (pkg). Для FreeBsd начиная с 8.4 установка происходит следующей командой
Код
# /usr/sbin/pkg
или, если первый выриант не сработал
Код
# cd /usr/ports/ports-mgmt/pkg
# make
# make install clean


6. Обновляем старые пакеты
Код
# pkg2ng

7. Обновляем базу pkg
Код
# pkg update -f

8. Проверяем версию пакета
Код
# pkg -v
На экран должна вывестись версия пакета.

Все теперь мы работаем с новым установщиком программ.

Просмотров:12603 0  

'bitrix:asd.share.buttons' is not a component

15 Февраля 2010 1:23

Оптимизация сервера FreeBSD

Заметки по технологии и оптимизации

Все что можно - преобразовывать в статику. Предгенерация контента.
Когда предгенерация не подходит - кэшируем динамику "на лету". Первый уровень - самые популярные и часто обновляемые блоки кешиурем в памяти (memcached). Второй уровень - редко запрашиваемые блоки кэшируем на диск. Кэшируем на уровне приложений. Чистим запись в кэше в момент изменения данных связанных с прокэшированными данными.
Буферизируем вывод apache через nginx. На уровне nginx реализуем базовые "url rewrite" правила, сжатие контента, перекодировку, средства борьбы с флудом, ограничения числа одновременных потоков. Возможна организация целостного кэширвоания страниц, через связку nginx+memcached с предварительным формированием кэша на уровне приложений.
Периодически парсим лог и выявляем пики дублирующих друг друга запросов к динамике (например, флуд через один и тот же сложный запрос к поисковой подсистеме), автоматически кэшируем результат таких запросов в статику и, пока не прекратится флуд, перенаправляем в статику. Также выявляем аномально больше число запросов динамики с одного IP, если при этом превышен допустимый Load Average, временно блокируем IP.
Со временем убедился, что персональные настройки на сайте - лишнее усложнение, почти всегда достаточно разумного дефолта. Стремлюсь к простоте в оформлении и лаконизму в изложении.
В динамике - поиск (возможно кэширование индексов популярных ключей через memcached), динамическая часть форума (возможно кэширование последних БД файлов, сессий и индексов в memcached. Перевод списочных страниц в статику, путем выставления new и флагов привязанных к пользователю через JavaScript), контент который не выгодно хранить или отдавать в статике:
когда контент слишком часто изменяется;
когда необходимо обеспечить большую гибкость запроса;
когда объем контента в статике слишком велик;
когда запрашивается только "верхушка айсберга" (например - вывод текста новостей, интенсивно запрашиваются только последние новости, которые и можно предкэшировать "на лету", но не предгенерировать);
когда предгенерация требует значительных ресурсов, несопоставимых с ресурсами затрачиваемыми при отдаче того-же динамикой (например, когда много вариантов представления - выгоднее предкэшировать отдельные блоки, а не всю страницу сразу).
Все что нельзя превратить в статику (предгенерировать) - кэшировать через статику. Предкэширование типовых запросов и промежуточное сохранение часто используемых выборок в кэше. Например, можно прокэшировать только наиболее часто встречающиеся запросы.
Ту динамику, что невозможно прокэшировать - снабжать средствами защиты от перегрузок.
защитой от DoS/flood потоков запросов;
ограничить число одновременных потоков на клиента;
ограничить число запросов на клиента в ед. времени (средства ipfw, mod_limitconn или mod_throttle);
квоты на дисковое пространство (не переусердствовать, отделить первичные области диска (например, хранилище БД, данные форума - не восстановимы), от вторичных (например, предгенирированный контент, кэши - влияют на отображение, но восстановимы из первичных областей) и третичных (например, логи - потеря не так страшна));
квоты на процессорное время
квоты на размер процесса;
квоты на число процессов;
Практические рекомендации по тюнингу Apache:
FreeBSD ядро собираем с "options ACCEPT_FILTER_HTTP" (или "kldload accf_http"), в конфигурацию Apache добавляем "AcceptFilter on", перезапускаем Apache;
Убираем лишние модули;
"KeepAlive Off", а картинки отдаем через отдельный мини-http сервер для отдачи статики (mathopd, thttpd, Nginx, lighttpd);
В "Options" должно быть "FollowSymLinks", но не нужно "SymLinksIfOwnerMatch" (приводит к лишней lstat() проверке при каждой отдаче файла).
Не используем .htaccess (AllowOverride None), все настройки, включая авторизацию, в httpd.conf (apache тратит ресурсы на попытки открыть .htaccess в каждой родительской директории);
Ограничиваем число одновременных запросов с одного IP через "ipfw add allow tcp from any to $IP 80 via fxp0 setup limit src-addr 15" или "iptables -A INPUT-p tcp --dport 80 -m iplimit --iplimit-above 10 -j REJECT", но не через модули apache (mod_throttle, mod_bandwidth, mod_limitconn);
Использовать FastCGI/mod_perl для динамики (устраивает использование FastCGI). Наиболее выгодно использовать для небольших скриптов, время загрузки и парсинга которых сравнимо с временем выполнения скрипта, либо если промежуточные данные можно держать в памяти (пример, скрипт "хинтов" в opennet). Выгода почти не ощутима для тяжелых скриптов, требующих значительного времени для выполнения и не использующих одни и те же области данных (например - скрипты поиска).
Использовать mod_accel - для буферизации клиентских запросов и создания внешнего кэша запросов к динамике. Увеличение sendbuffer в apache и send/recv буферов на уровне ОС. Написание скриптов с учетов кэширования. (в opennet mod_accel не используется)
Использовать mod_deflate для сжатия отдаваемого пользователям контента (трафика меньше и клиенту быстрее информация отдается, нагрузка на CPU от сжатия - почти незаметна);
Если статики очень много (например отдаются картинки) - не тратим на нее силы apache, а отдаем через nginx. Окажет помощь балансировка данных на несколько дисков, особенно если на сервере используются SCSI накопители. Или выдача статики прямо из memcached или ram-диска.
Надежность

Для обеспечения надежности системы важными составляющими являются системы мониторинга и резервного копирования.
Мониторинг.
Слежение за возникновением проблем
Попытки автономно решить проблему
Оперативное сообщение о возникновении проблемы.
Сохранение информации о факте проблемы и дампа состояния системы в момент проблемы.
Визуализация текущего состояния.
Визуализация динамики изменения состояния (наглядное представление на графиках):
Мониторинг инфраструктуры (группы серверов и оборудования)
Карта сети, в которой отображено состояние точек и связей
Удаленный мониторинг
Достижимость ресурса
Работоспособность сервисов ресурса
Локальный мониторинг
Контроль наличия запущенных процессов
Контроль за состоянием процессов (число процессов, расход ресурсов CPU, ОЗУ)
Контроль за состоянием сетевых соединений (определение флуда)
Контроль расхода дискового пространства.
Периодическая оценка логов на предмет наличия фатальных или предупреждающих сообщений.
Контроль общего состояния системы, нагрузки, расхода памяти, сетевого трафика и т.д.
Резервное копирование.
Территориальный вынос бэкапа (пожар, форс-мажор)
Инкрементальное накопление изменений
Несколько уровней отката.
Несколько уровней детализации и полноты бэкапа.
Безопасность и конфиденциальность бэкапа (бэкап с важными данными должен быть зашифрован)
Экономия дискового пространства за счет сжатия бэкапа.
Легкость восстановления без необходимости доп. ПО, кроме архива бэкапа (открытый формат архива)
Автономность, автоматическая работа без участия оператора
Гибкость формирования бэкапа (маски файлов/директорий для помещения в бэкап и исключения из него)
Схема и планирование бэкапа.
На критичные к времени простоя или содержащие ценные данные сервера, ставим RAID. Обязательно, hi-end SCSI диски, хороший SCSI RAID контроллер (сейчас используем LSI Logic SCSI 320-2 MegaRAID, RAID5 + hot-spare). Не стоит экономить при выборе контроллера, лучше без RAID, чем чувство ложной безопасности). Наличие BBU (аккумулятор для сохранения содержимого кеша в течении нескольких суток) крайне желательно, иначе при пропадании питания вероятен серьезный сбой (ОС считает что данные записались, а реально нет). Крайне рекомендуется иметь запасной hot-spare диск для автоматической горячей замены.
Восстановление после сбоя производится автоматически (время простоя нулевое).
Если бюджет не позволяет установить хороший RAID контроллер, следует добавить на сервер IDE диск большого размера и еженощно зеркалировать туда всю информацию. Рекомендуется, использовать двойное зеркало, каждое из которых обновляется через день. Подобная перестраховка необходима для предотвращения потери данных в ситуации краха во время бэкапа и защиты от синхронизации в бэкап не фатальных повреждений ФС ведущих к пропаданию файлов (сбой, fsck, случайное удаление) или их обнулению (следствие переполнения раздела).
Для восстановления необходимо загрузить систему с бэкап диска (несколько минут)
Ежедневное инкрементальное резервное копирование уникальных для данного хоста данных и файлов конфигурации на территориально удаленный бэкап сервер (например, используя fsbackup).
Для восстановления следует установить операционную систему и восстановить конфигурацию и данные из бэкапа (простой - несколько часов).
Обязательным звеном бэкапа является проведение эксперимента по восстановлению системы. В ходе такого эксперимента всплывают не помещенные в бэкап важные файлы, отсутствие сведений о конфигурации системы (например, параметры дисковых разделов). Кроме того, благодаря четкому представлению шагов и уверенности в действиях, увеличивается скорость восстановления после реального сбоя, уменьшается вероятность человеческой ошибки.
Дополнительные системы отказоустойчивости: разбалансировка на несколько серверов (самое простое - балансировка по DNS) или БД, использование RAID, системы бесперебойного питания, резервные сетевые линки, промежуточное оборудование повышенной надежности (маршрутизаторы, коммутаторы), размещение в спец. помещении (неприкосновенность оборудование, вентиляция, фильтрование пыли, температурный режим, защита от пожара и протечки систем водоснабжения).
Дополнительные системы увеличения производительности
Кэширование контента.
Кэширование SQL запросов.
Кэширование промежуточных данных
Кэширование результата.
Предкешированные объекты.
Использование оптимальных алгоритмов.
Оборудование - SCSI диски, машины с SMP.
Тюнинг ОС.
Разделение нагрузки на несколько серверов, вынос сервисов на отдельные машины.
Функциональное разделение (по IP) и равномерное разделение (SQL)
Субъективное разделение (разделение функций и операций, DNS-балансирование, IP-балансирование и т.д.)
Разделение процессов (кластер, 2 SQL сервера для балансировки SELECT запросов.)
Безопасность

Ежедневное слежение за отчетами с описанием новых проблем с безопасностью в рассылках и на специализированных сайтах.
Не дожидаться обнаружения ошибок, попытаться предотвратить их проявление. Всегда считать, что в программе есть ошибки, обдумать что можно сделать чтобы система не пострадала от их проявления. Система должна быть неприступна, невзирая на вероятные проблемы с безопасностью в программах.
Избыточные, параноидальные проверки в своем коде. Проверки на каждом этапе использования полученных от пользователя или иного внешнего источника данных.
Понижение привилегий и запуск в chroot.
Использование библиотек-врапперов подменяющих потенциально опасные библиотечные вызовы или сборка спец компиляторами с средствами защиты от переполнения буфера.
Сниффинг. Особое внимание следует уделить внутренней безопасности, для предотвращения появления злоумышленника в доверительной сети. Сниффер в доверительной сети, не меньшая угроза, чем открытая брешь в ПО. Средства защиты от злоумышленника в локальной сети:
Шифрование трафика, особенно актуально для сервисов в которых присутствует передача паролей в открытом виде. Но, на одно шифрование тоже нельзя полагаться, об этом ярко говорят ошибки в реализации ssh1, openssl, mod_ssl приводящие к возможности анализа перехваченного шифрованного трафика.
(Примеры, замены: http => SSL+http, ftp => sftp, telnet, ssh1 => ssh2, pop3 => apop или pop over TLS/SSL).
Жесткая политика доступа к ресурсам управления (ssh, snmp).
Разграничение доступа внутренними средствами: ACL программы или tcp wrapper (/etc/hosts.allow). Желательно, чтобы доступ разграничивался как по имени пользователя совместно с ограничением по IP (каким пользователям какие действия можно производить с каких IP).
Дублирующее ограничение средствами фаервола, можно как на локальном сервере, так и на пограничном маршрутизаторе.
Мониторинг переполнения ARP таблиц. Использование коммутаторов (свичей), не избавляет от возможности сниффинга. Проброс каждого клиента используя VLAN через маршрутизатор или привязка MAC адреса к порту коммутатора - дорогое удовольствие, особенно в больших сетях. Частично проблему помогают решить программные средства слежения за изменением MAC адресов (чтобы пользователи самовольно не меняли IP адреса и не выставляли IP соседа) и мониторинга за переполнением ARP таблиц. Другой способ борьбы с arp-спуффингом - использование специальных патчей на шлюзовой машине или жесткая привязка MAC адресов к IP.
Использование временных паролей (One-Time Passwords - OTP, opie, s/key). Например, генерируется список паролей и при каждом входе используется следующий пароль из списка, использованные пароли блокируются.
Применение средств автоматического обнаружения вторжения (IDS) под вопросом, так как в таких средствах часто находят критичные ошибки способствующие взлому (пример: snort, tcpdump).
Закрытая система для решения спец. задач, без публичных сервисов (например, рутер, фаервол)
Полное отсутствие сетевых сервисов.
SSH доступ только с IP администратора и резервного trusted сервера.
Закрытые сервисы доступны только непосредственным потребителям.
Двойное или тройное блокирование, пакетный фильтр, libwrap/tcpwrapper и настройки самой программы.
Если система не в trusted сети - шифрование всех потоков данных.
Закрытая система с сетевыми сервисами.
SSH доступ только с IP администратора и резервного trusted сервера.
Открыты только реально необходимые сервисы.
Для открытых сервисов используется только доверительное ПО, в котором ранее не замечали проблем безопасности и прошедшее беглый аудит.
Все остальное, если невозможно обойтись без него или заменить в CHROOT.
Доверяю ПО: postfix, qmail, popa3d, vsftpd (практика прецедента - не доверять ПО в котором хоть раз найдена критическая ошибка безопасности или программа разработана без использования жесткой политики безопасности (в документации и коде это сразу заметно)).
Запускаю в CHROOT: bind/named, apache, ftpd (BSD), inn. Доступ к OpenSSH только с доверительных хостов.
Не запускаю в public никогда: все реализации IMAP, samba, sendmail, proftpd, wuftpd, mysql, postgresql, dhcpd, ntpd. Пример особенно безграмотных с точки зрения безопасности систем - proftpd, qpop.
Не использовать антивирусы для проверки почты, как правило это закрытые проекты в которых не проводится аудит исходного кода. Вместо антивирусов, можно практиковать полную блокировку пересылки выполняемых файлов, или отключить проверку в архивах и запускать в chroot. Подобному решению способствуют прецеденты DoS атак (переполнение диска) через вложенные, специально скомпонованные, сжатые файлы или возможность выполнения кода на сервере через специальным образом скомпонованные заголовки письма.
Открытая система с локальными пользователями (например пользователи могут запускать CGI-скрипты)
Разделение привилегий, запретить доступ к другим пользователям и системным файлам по возможности
Желательно noexec /tmp и патч для noexec stack.
Если можно то в chroot jail.
Не давать исходящих коннектов, если не требуют условия.
Убрать все suid программы которые можно убрать, использовать TCB для хранения паролей, вместо /etc/shadow
Не оставлять бэкапы в открытом месте, иногда злоумышленник может взломать систему используя старую suid программу из бэкапа или обнаружив общедоступный файл с паролями.
Вести подробные логи, включая аккаунтинг выполняемых процессов. syslog логи дублировать по сети на соседнюю машину.
Применять программное обеспечения для слежения за целостностью участков файловой системы и поиска root-китов.
Дополнительные ограничения для скриптов пользователей системы хостинга (apache в chroot):
Запрещение connect(2), невозможность установки исходящих соединений пользовательскими скриптами (используя библиотеку враппер, подгружаемую через LD_PRELOAD в suexec, принудительно меняем для listen и connect IP на 127.0.0.1).
Запрещение listen(2), предотвращение приема соединений на сетевой порт. Борьба с процессами демонами, через мониторинг.
Ограничение возможности использования группы exec вызовов, предусмотреть использование относительных путей и список исключений (текущая cgi-bin, /bin и т.д.);
Запретить для cgi-скриптов возможность создания и перезаписи файлов в директориях с исполняемыми скриптами (cgi-bin).
Квоты на дисковое пространство, время выполнения скрипта и объем используемой одним скрптом памяти.
Права доступа к диреткории пользователя "drwx--x--- user hosting", где user - id пользователя, hosting - группа из под которой запущен apache (для раздачи статики). Таким образом скрипт пользователя не имеет доступа к диреториям других пользователей.
Использование mod_php в режиме safe_mode (php_admin_flag safe_mode on), запретить использование URL в open (php_admin_flag allow_url_fopen off), ограничить обем ОЗУ (php_admin_value memory_limit 2M), ограничить время выполнения (php_admin_value max_execution_time 10).
Мониторинг in/out трафика через mod_watch. Раньше получал полные данные о трафике используя "per user ip accounting", но он учитывал также mysql и прочий локальный трафик, после введения блокировки на listen() и connect(), использование mod_watch вполне оправдано. Предотвращение использование ftp аккаунта для файлового обмена, через дополнительный мониторинг.
Аспекты безопасности при написании CGI-скриптов
Применение suexec и жесткое разграничение прав доступа (пользователь не должен видеть системных файлов и логов, не должен иметь возможность получить доступ к данным другого пользователя)
Полностью исключить использование типовых бесплатных скриптов. Лучше все писать самостоятельно, если написание затруднено - обязателен полный аудит кода чужих скриптов.
Паранойя при написании кода - дублирующие проверки всех параметров получаемых в диалоге скрипта с пользователем (как минимум проверка валидности с выводом сообщения об ошибке на этапе инициализации переменных с данными пользователя и жесткое вырезание недопустимых символов (s/[^\w\d_\-.]//g) перед опасными функциями (open, system)), обязательное экранирование переменных при использование в regex выражении (/\Q$var\E/, иначе $var может содержать "?{код}").
Perl пишем на Perl: никаких `` и вызовов shell функций, скрипт с perl -w и в strict режиме;
Перед написанием кода - обязательное планирование, перед кодированием скрипт должен уже иметь четкую структуру.
После написание - отладка и crash тест.
Доступ к системе web-управления, только с "trusted" хостов, желательно по HTTPS.
Защита обслуживаемой сети c пользователями.
Оборудование и рабочее место администратора не должны быть подключены в рамках одной физической сети (см. выше пункт "сниффинг"). Желательно разделить сеть по отделам (директора и бухгалтерию подключить отдельно).
Не допустить доступ к оборудованию посторонним (охрана, дети сотрудников). Обязательная парольная аутентификация на каждой машине и жесткие административные правила пользования сетью.
Машины сети снабдить IP адресами из интранет блока. Выход во вне только через прокси или транслятор адресов. Фаерволом закрыть все кроме необходимых сервисов.
Установка локального ПО для борьбы с вирусами, постоянное обновление пользовательских систем (установка service pack) и программ для работы в сети (IE, Opera, The Bat, Outlook).
Повышение грамотности пользователей.
Мониторинг уязвимостей в локальной сети, средства сканирования пользовательских машин на предмет известных уязвимостей.
Защита от DoS и DDoS.
Тюнинг системы и установка лимитов, недопускающих полного исчерпания системных буферов и уход в своппинг, при исчерпании ОЗУ. Лимиты httpd и скриптов должны быть всегда чуть ниже реальных возможностей системы.
На готове должен быть скрипт для составления черных списков IP, на основе выявленной аномалии, присущей текущей атаке (запрос одинаковой страницы; запрос только контентообразующих страниц, без сопутствующих css, js и картинок; аномально высокое число запросв с одного IP; невыполнение javascript вставок; невосприятие cookie).
Списки IP адресов подключаем не через отдельные правила пакетного фильтра, а через функциональность работы с таблицами адресов. В особо тяжелых случаях можно блокировать на вышестоящем маршрутизаторе блоки адресов, оставив только адреса стран, составляющих костяк посетителей сайта.
Если бот не умеет парсить JavaScript, хорошо помогает использование промежуточной javascript страницы минимального размера. На все запросы отдаем сперва простейшую страницу (только скрипт с document.location='http://www.site.ru/real/page.html') с редиректом на реальную страницу (определяем через rewrite и if в nginx). Плюсы: страница отдается из кэша, без обращения к диску; страница минимизирует трафик, влазит в 1 tcp пакет; если был запрос фиктивной страницы, но не было последующего запроса реальной, можно помещать IP в список блокировки.
Расчет лимитов предусматривающих возможность удаленного входа администратора при любой нагрузке. Например, каков бы ни был лимит на число соединений, ограничение пропускной способности сети и ограничение числа запросов через пакетный фильтр, администратор всегда должен иметь возможность удаленно попасть на машину. Для IP администратора делаем отдельные разрешающие правила и выделяем небольшую гарантированную полосу пропускания.


Источник http://www.opennet.ru/guide.shtml#tune

Просмотров:3032 0   Комментариев:0

'bitrix:asd.share.buttons' is not a component

4 Января 2010 13:45

FreeBSD: установка eAccelerator

Устанавливаем eAccelerator из портов:
Код
# cd /usr/ports/www/eaccelerator
# make install clean


Заходим в файл '/usr/local/etc/php/extensions.ini' и создаем секцию:
Код
[eAccelerator]
;Подключаем библиотеку
zend_extension=eaccelerator.so
;Количество выделяемой кеш-памяти на жестком диске для скомпилированных акселератором скриптов, Мб
eaccelerator.shm_size="256" 
;Время жизни скрипта
eaccelerator.shm_ttl="3600" 
;Обключаем режим отладки
eaccelerator.debug="0"


Создаем папку, где eAccelerator будет хранить свой кэш, задаем владельца www и устанавливаем права:

Код
# mkdir /tmp/eaccelerator
# chown www /tmp/eaccelerator
# chmod 0700 /tmp/eaccelerator


Перегружаем apache
Код
apachectl restart

Просмотров:4592 0   Комментариев:59

'bitrix:asd.share.buttons' is not a component

IT-технологии
WEB сервера, настройка и конфигурирование, интересные решения
Программирование
WEB программирование, WEB дизайн, Кросс-браузерная верстка
Технические науки
Физика, Математика, Химия и все-то, что лежит в основе наших знаний