Вот, как сделать, чтобы отправить письмо, содержащее текст, скачанный со страницы wget’ом:
/usr/bin/wget -O - http://site.com/news.php | mail -s "hello, wget" [email protected]
Исследования в области SEO, трафик и техничка
Вот, как сделать, чтобы отправить письмо, содержащее текст, скачанный со страницы wget’ом:
/usr/bin/wget -O - http://site.com/news.php | mail -s "hello, wget" [email protected]
Данная статья имеет смысл, если на сервере установлен Nginx.
Для начала изменяем конфиг Nginx, чтобы в лог выводились имена сайтов, к которым идет обращение:
# vi /etc/nginx/nginx.conf
Меняем строку
access_log /var/log/nginx/access.log;
На
log_format main ‘$remote_addr — $remote_user [$time_local] $status «$host» «$request» $body_bytes_sent «$http_referer» «$http_user_agent» «$http_x_forwarded_for»‘;
access_log /var/log/nginx/access.log main;
И перезапускаем nginx:
# invoke-rc.d nginx restart
Если установлен Apache, то его желательно отключить, чтобы сервер не повис от нагрузки от атаки.
# invoke-rc.d apache2 stop
После чего ждем, чтобы access.log «поднакопил» данные от запросов.
Через некоторое время можно останавливать nginx и запускать следующую команду:
# tail -n 1000 /var/nginx/access.log | awk ‘{print $7}’ | sort | uniq -c | sort -n
Таким образом, мы получим данные в виде имен сайтов и количестве обращений к ним.
А вот так выглядет команда на получение списка IP, с которых шли запросы:
# tail -n 1000 /var/log/nginx/access.log | awk ‘{print $1}’ | sort | uniq -c | sort -n
Есть и более простой вариант.
После того, как мы сделали свой log_format в Nginx и перезапустили его, можно просто запустить:
# tail -f /var/log/nginx/access.log
И мониторить запросы на наличие корректного браузера, реферрера и т.д.
Такие же манипуляции можно производить и с error.log’ом.
Для начала обновляем информацию о пакетах:
# apt-get update
Устанавливаем subversion и mod_dav
# apt-get install subversion libapache2-svn
Создаем папку с репозиторием:
# mkdir /var/www/svn
Меняем владельца на www-data:
# chown www-data:www-data /var/www/svn
Настраиваем dav_svn
# nano /etc/apache2/mods-enabled/dav_svn.conf
Приводим к такому виду:
<Location /svn>DAV svnSVNParentPath /var/www/svnAuthType BasicAuthName «Subversion Repository»AuthUserFile /etc/apache2/dav_svn.passwdRequire valid-user</Location>
# touch /etc/apache2/dav_svn.passwd
# /etc/init.d/apache2 restart
# htpasswd /etc/apache2/dav_svn.passwd user_name
Если Вы ставили ограничение на вход в ISPmanager по IP и у Вас он сменился, достаточно просто изменить IP (в файле) или удалить этот файл:
/usr/local/ispmgr/var/userconf/ispmgr.root
Сначала обновляем информацию о пакетах:
# apt-get update
Устанавливаем пакет php-pear
# apt-get install php-pear
Устанавливаем PEAR\HTTP_REQUEST
# pear install —alldeps HTTP_REQUEST
Перезапускаем апач:
# /etc/init.d/apache2 restart
Делается так:
cd /usr/ports/sysutils/smartmontools && make install clean
И проверяем диск. К примеру:
/usr/local/sbin/smartctl -a /dev/ad4
А вот здесь:
/usr/local/ispmgr/www/disabled/index.html
Установка проста до безумия. Вот так:
Устанавливаем
# apt-get update && apt-get install php5-imagick imagemagick -y
И перезапускаем веб сервер:
# /etc/init.d/apache2 restart
Вот, понадобилось вернуть стандартную для stable Debian версию PHP — 5.2.х.
Версия Debian 5.0.7
Для начала редактируем файл /etc/apt/sources.list
В моём случае нужно было удалить/закомментировать эти строчки:
deb http://php53.dotdeb.org stable all
deb-src http://php53.dotdeb.org stable all
Удаляем PHP:
# aptitude purge -y php5-cli php5-cgi php5-common
Далее обновляем информацию о пакетах:
# aptitude update
Обновляем кеш ISPManager’a:
# /usr/local/ispmgr/sbin/pkgctl cache
И устанавливаем PHP:
# /usr/local/ispmgr/sbin/pkgctl install php
Необходимо будет еще установить PHPMyAdmin и Webmail, если требуется.
При заходе на http://site.com/manager — открывается ISPManager, а не админка MODx’a.
Решение такое.
Открываем ispmgr.inc:
# vi /usr/local/ispmgr/etc/ispmgr.inc
И меняем
Alias /manager /usr/local/ispmgr/bin/
На
Alias /ispmanager /usr/local/ispmgr/bin/
Сохраняем, закрываем.
Рестартим апач: (В Debian)
# /etc/init.d/apache2 restart
В CentOS:
# service httpd restart
Все. Теперь по адресу http://site.com/ispmanager — у нас будет открываться ISPManager
Ставится так.
32 bit:
# rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm
64 bit:
# rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/x86_64/epel-release-5-4.noarch.rpm
В кратце:
Имеем FreeBSD.
Логиниться на SSH рутом запрещено, есть доступ под рутом в ISPManager. Создаем нового пользователя, напрмер sharkov.
Даем права на shell. Логинимся на ssh. Вводим su и видим:
su: Sorry
А это значит, что пользователь не состоит в группе wheel. Через midterm так же не пускает (ну ессно же =) ).
В общем нужно как-то посадить юзера в группу wheel. (Ну можно еще через встроенный файловый менеджер это сделать, или отредоктировать конфиг ssh). Но мы легких путей не ищем.
Вот мой извращенческий способ:
Добавляем задачу в крон (планировщик задач):
/usr/sbin/pw user mod sharkov -G wheel
И запускаем.
Если появилась такая ошибка в error_log’e, значит у Вас неверный хостнейм.
Решаем так:
# echo ‘site.com’ > /proc/sys/kernel/hostname
Меняем хостнейм в /etc/hostname
И перезапускаем в Debian:
# /etc/init.d/apache2 restart
В CentOS:
# service httpd restart
Все просто.
Заходим в папку с файлами. Вводим:
# svn info
Видим URL:
URL: file:///var/www/svn/site/branches/production
Теперь меняем на новый командой svn switch:
svn switch —relocate file:///var/www/svn/site/branches/production http://my.ip.add.r/svn/site/branches/production
Первый URL — адрес старого репозитория,
Второй — нового.
Убеждаемся, что все ОК:
# svn info
URL: http://my.ip.add.r/svn/site/branches/production
Вот так.
При скачивании и распаковке портов имеем ошибки:
# portsnap fetch && portsnap extract
Looking up portsnap.FreeBSD.org mirrors… 5 mirrors found.
Fetching snapshot tag from portsnap2.FreeBSD.org… done.
Fetching snapshot metadata… done.
Updating from Tue Nov 9 14:35:59 MSK 2010 to Sat Nov 13 13:01:26 MSK 2010.
Fetching 1 metadata patches. done.
Applying metadata patches… done.
Fetching 0 metadata files… done.
gunzip: can’t stat: files/18e2c2d3e5e2ba6583fbe574fba1fa36efc7887046f25d20dd79971dd7b16390.gz: No such file or directory
Fetching 0 patches. done.
Applying patches… done.
Fetching 0 new ports or files… done.
Building new INDEX files… gunzip: can’t stat: /var/db/portsnap/files/c18a355ef772b8d5deaee48dcc48dc86e06a4252f7f4441a521621d194e9e0fb.gz: No such file or directory
gunzip: can’t stat: /var/db/portsnap/files/1ac36646f895592a28adc8af555c941402082a5ea43955c0e669324122ff28fe.gz: No such file or directory
done.
Решение:
Удаляем тэги и все, что связано со старым деревом:
# rm /var/db/portsnap/tag
# rm -rf /var/db/portsnap/files
# rm -rf /usr/ports
Скачиваеи и обновляем:
# portsnap fetch && portsnap extract
Готово!