Здравствуйте,

было получено сообщение о недоступности Вашего ВПСа, после перезагрузки, Ваш ВПС не запустился, вынуждены были сделать релоад ОС,

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

Пиздец, дорогая редакция. Ваше ядро не загрузилось, мы накатали вам новую ось.

Если забыл пароль root в MySQL, но имеешь рута на сервер, то заменить пароль очень просто.

Редактируем /etc/my.cnf (ну или где там он у вас) и вставляем в секцию [mysqld] строку:

skip-grant-tables

mysql -u root mysql

UPDATE USER SET password=password('NEWPASS') WHERE USER='root' AND `host`='localhost`;

Убираем skip-grant-tables из my.cnf, рестартуем mysqld.

Теперь пароль для root@localhost будет NEWPASS.

Поставили VPN, соединились, все! Никто нас не отследит, СОРМ – кашляй. Однако, есть ньюансы!

Во-первых, зачастую VPN ставится на дефолтный айпи сервера.

Во-вторых, на дефолтном айпи сервера зачастую располагаются некоторые ресурсы вебмастера. Ну там, сайты, админки, FTP, Jabber…

В-третьих, любой VPN-клиент первым делом создает прямую роуту на этот самый айпи, дабы не терять соединение с сервером после соединения с сервером. Бррр. Ну, понятно к чему это я?

К тому что весь трафик на этот айпи, на который вы коннектитесь VPN-клиентом, не шифруется.

Не верите? Проверьте с помощью tracert ))

Пуск-выполнить
tracert VPN-IP
tracert my-site-on-this-ip.com
tracert my-ftp-on-this-ip.com

Что же делать?

Айпи, на который коннектиться ваш клиент VPN – не должен быть привязан к каким либо сервисам: фтп, www и т.д. Он должен быть полностью выделенным под VPN.

#!/bin/bash
while /bin/true ; do
   /usr/bin/mplayer "/home/user/music/cf/Cradle Of Filth - Nymphetamine.mp3"
   sleep 5
done

Сохраняю, ставлю в крон на нужное время и спаааааать. mplayer в списке процессов я смогу покилять точно когда проснусь.

Да, за это я люблю Linux.

После двух дней долбления башкой об клаву поднялся образ iATKOS v7. И на обычном KVM (intel) и на Proxmox KVM (AMD).

Из особенностей подъема:

• Видеокарта Standard VGA
• Опции при загрузке (нажать F8 перед загрузкой): -cpus=1 -v -x -f platform=acpi idlehalt=0

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

hosted-by:/> stat /var/www/admin/data/mod-tmp
  File: `/var/www/admin/data/mod-tmp'
  Size: 1022976000      Blocks: 1999960    IO Block: 4096   directory
Device: 802h/2050d      Inode: 11403505    Links: 2
Access: (2700/drwx--S---)  Uid: (   33/www-data)   Gid: (  502/   admin)
Access: 2011-05-30 23:44:44.000000000 +0300
Modify: 2011-05-30 08:36:27.000000000 +0300
Change: 2011-05-30 08:36:27.000000000 +0300

При попытке просмотра папочки, ls задумывается минут на 20, а потом выдает:

hosted-by:/> ls -1 /var/www/admin/data/mod-tmp > /tmp/ls
ls: memory exhausted

Поступили жалобы на «некорректную работу сервера». Да я думаю некорректная…

hosted-by:/> df -i
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/sda2            14884864 14884864       0  100% /

Найти потенциальных пожирателей инод смог по команде

find / -type d -size +100k -print

На этой папочке find заткнулся навечно, что навело на мысль.

Диагноз: рак. Лечение: ампутация.

screen
rm -rf /var/www/admin/data/mod-tmp && mkdir /var/www/admin/data/mod-tmp && chmod 777 /var/www/admin/data/mod-tmp

При скорости удаления около 100 файлов в секунду, а файлов более 10 млн, можно идти спать….

Дальнейшее вскрытие показало что в папочке были файлы сессий php. На Debian Lenny почему то выпиливатель старых файлов сессий выключен по дефолту:

hosted-by:~> grep -B 5 session.gc_probability /etc/php5/apache2/php.ini
 
; This is disabled in the Debian packages, due to the strict permissions
; on /var/lib/php5.  Instead of setting this here, see the cronjob at
; /etc/cron.d/php5, which uses the session.gc_maxlifetime setting below.
; php scripts using their own session.save_path should make sure garbage
; collection is enabled by setting session.gc_probability
;session.gc_probability = 0

Вопиющее распиздяйство. Хотя скорей всего дело в нестандартном расположении session.save_path, который ставит ISP Manager.

Ставим mod_evasive, в конфигурации пишем

DOSHashTableSize    3097
DOSPageCount        15
DOSSiteCount        15
DOSPageInterval     3
DOSSiteInterval     3
DOSBlockingPeriod   300
DOSSystemCommand    "/usr/bin/sudo /usr/bin/fwban %s"

• DOSPageInterval – интервал для хитов определенной страницы
• DOSSiteInterval – интервал для хитов определенного vhost
• DOSPageCount – после этого количества хитов по определенному URI в течении интервала DOSPageInterval, айпи будет забанен
• DOSSiteCount – после этого количества хитов по определенному vhost в течении интервала DOSSiteInterval, айпи будет забанен

Нам понадобиться скрипт для бана на уровне файрвола «/usr/bin/fwban» (вариант для Linux):

#!/bin/bash
if [ "x$1" = "x" ] ; then
    echo "USAGE: $0 IPADDR"
    exit
fi
/sbin/iptables -A BAN -s $1 -j DROP

Ему надо поставить права 755.

Так же нам понадобиться утилита sudo. Она стоит практически везде. В «visudo» закомментируем опцию:

#Defaults    requiretty

apache  ALL = NOPASSWD: /usr/bin/fwban

Так же нам понадобиться цепочка BAN в iptables:

iptables -N BAN
iptables -I INPUT -j BAN

Сохраним правила файрвола

/etc/init.d/iptables save

Рестартанем апач. Теперь попробуйте уложить ваш сайт (только не со своего айпи!!!):

ab -n 1000  -c 20 http://yoursite.info/

В логах «жертвы» можно увидеть:

May  6 15:18:25 Server1 mod_evasive[26514]: Blacklisting address 1.2.3.4: possible DoS attack.

# iptables-save
---многа букав---
-A BAN -s 1.2.3.4 -j DROP
---многа букав---

Да. И конечно, апач лучше бы прикрыть извне nginx’ом.

Да. И данный метод банит айпишнеги перманентно, пока не рестартанет сервер, или не будет сброшена цепочка BAN. Вот такой брутальный метод )

Слышал что есть платная версия XenServer… Я, чес говоря, не понимаю за что там платить деньги.

1. Теневое копирование. Это такой своеобразный аналог LVM snapshot, запиленый программистами Cytrix, который позволяет создавать копии многогигабайтных разделов на лету. Если быть точнее, создается COW раздел, куда пишутся изменения нового тома. Самое интересное, что этот COW раздел никогда не становится самостоятельным, если не сделать этого руками. В результате, если вы создали виртуалку из шаблона или из другой виртуалки, используя т.н. «Быстрое копирование диска» (по умолчанию), то знайте: свободное место в хранилище рано или поздно закончится. Еще более интересен факт того, что из-под такого тома место не освобождается даже когда виртуалка удалена. В версии XenServer 5.6 выпущен костыль в виде периодически стартующей задачи, которая периодически отсоединяет найденные COW клоны томов и делает их независимыми. Но я бы не назвал это полноценным решением проблемы.
2. Конфликт версий в пулле. Представим ситуацию. Ваше железо, на котором установлен XenServer, издало предсмертный писк и по-тихоньку катится в историю. Вы в панике ставите рядом здоровую железяку, ставите на нее XenServer и пытаетесь ее добавить в пул, дабы на лету перетянуть виртуалки с умирающей тачки. Но вот незадача. На старой тачке стоял XenServer 5.5, а на новой вы поставили 5.6. И по этому вам не удастся добавить новый сервер в пулл и сделать миграцию на лету. Матюкаясь, вам прийдется на старом монтировать NFS, останавливать виртуалки и бекапать их на NFS, а на новом восстанавливать. Но даже при одинаковых версиях, вам придется пройти нехилый квест для понимания, из-за каких софтварных конфликтов сервак не хочет добавляться в пулл.
3. Фантомные виртуалки. Вообще, я не догоняю как у наших программистов получилось это сделать не единожды. Но программисты на то и программисты, дабы делать невозможное. Вобщем смысл в том, что при каких то обстоятельствах бекапа-восстановления, на сервере появляются две идентичные виртуалки. У них одинаковая конфигурация, одинаковые MAC адреса, одинаковое имя, но разные UUID. Я думаю из-за одинаковых имен XenCenter их не отображает в списке. Вы видите в списке только одну виртуалку. А фантома вы не видите, но он есть и он запущен. Ну прям как тот суслик из ДМБ. Я думаю все догадаются какими проблемами пахнут две сетевухи в одной сети с одинаковыми MAC адресами. Фантомов можно вычислить только из командной строки «xm vm-list». Только там можно увидеть клонов и убить их по UUID. Правда сначала надо будет разрулить ситуацию split brain, то есть определить, кто из клонов содержит в себе наиболее свежие данные.
4. А еще под XenServer не запускается FreeBSD. Точнее запускается, но не любая, не на любом железе и с большими костылями.

Таким образом получается, что одни и те же cron скрипты выполняют одни и те же задачи одновременно, удваивая тем самым нагрузку. При этом они начинают выполняться медленнее, и возможна лавинообразная ситуация, когда к этим двум добавится еще и третья такая же задача. Потом четвертая, а потом все упадет вообще.

Как с этим бороться?

Вариант 1. Сложный.

Использовать в скрипте, который запускается по cron, проверку pid:

1. Проверяем наличие pid файла с идентификатором процесса
2. Проверяем, есть ли такой pid в памяти командой «ps -p PID»
3. Если pid запущен, прерываем работу
4. Иначе, пишем в pid файл свой pid и продолжаем

Однако это требует модификации скрипта.

Вариант 2. Простой.

Есть замечательная утилитка в Linux, называется flock (1). В качестве параметра, утилита принимает имя файла лока и команду для исполнения. flock ставит эксклюзивный лок на указанный файл и, при успехе, запускает указанную команду. Функционал flock не ограничивается только этой возможностью – на эту тему можно покурить соответствующий man.

Итак, у нас есть cron задача:

* * * * *   user  /usr/bin/php /some/heavy/script.php

С помощью небольшой модификации этой строки мы сможем предотвратить повторный запуск задачи во время выполнения предыдущей задачи:

* * * * *   user  /usr/bin/flock -xn /var/lock/script.lock -c '/usr/bin/php /some/heavy/script.php'

Ну собсно все.