FastNetMon

Показаны сообщения с ярлыком ISPManager. Показать все сообщения
Показаны сообщения с ярлыком ISPManager. Показать все сообщения

среда, 23 апреля 2014 г.

Где хранит свои сессии ISPManager?

Как можно догадаться, как при работе по API (mgrctl -m ispmgr session.newkey username=root key=$key), так и при работе через веб ISPManager поддерживает свои сессии. В которых лежит секретный код (в случае веба - хранится в куке), который позволяет входить пользователю без пароля пока действительна его сессия.


Путем отладки через starce нашел, что этот файлик вот тут:
 /usr/local/ispmgr/var/.ispmgr.ses
Но вот его формат не понятен, хотя скоро, уверен, я его вскрою и выложу концепт :) Формат у него страшный и бинарный =)
 

суббота, 29 января 2011 г.

ISPManager: WARNING Bad UTF8 string

Имеем вот такую радость на ISPManager Lite:
Jan 29 21:21:30 [27760] WARNING Bad UTF8 string '"??#??.0??'
Jan 29 21:21:30 [27760] ../../src/mgr/libmgr/xmlutil.cpp:236 DEBUG fixed to '"??#??.0??'
Jan 29 21:22:49 [27760] INFO Request [89.223.25.225][root] 'func=domain&clickstat=yes'
Jan 29 21:22:49 [27760] ../../src/mgr/core/session.cpp:2132 TRACE Attach messages to banners
Jan 29 21:22:49 [27760] ../../src/ispmgr/core/ispmgr.cpp:59 TRACE Rebuild AccountCache
Jan 29 21:22:49 [27760] ../../src/ispmgr/core/ispmgr.cpp:191 DEBUG Total accounts 4046
Jan 29 21:22:50 [27760] WARNING Bad UTF8 string '????#??#????.0??'
Jan 29 21:22:50 [27760] ../../src/mgr/libmgr/xmlutil.cpp:236 DEBUG fixed to '????#??#????.0??'
Jan 29 21:22:50 [27760] WARNING Bad UTF8 string '"??#??.0??'
Jan 29 21:22:50 [27760] ../../src/mgr/libmgr/xmlutil.cpp:236 DEBUG fixed to '"??#??.0??'

Фиксится - лишь апдейтом панели.

понедельник, 13 декабря 2010 г.

Как привязать пользователя ISPManager к определенному IP?

vi /usr/local/ispmgr/var/userconf/ispmgr.username

И добавляем строчку:
Access ip_addr

После этого перезапускаем ISPManager:
killall ispmgr

После данных операций пользователь username сможет входить лишь с данного IP.

пятница, 5 ноября 2010 г.

Крайне интересным образом ISPManager выключает базы данных

select * from mysql.user where User = 'someuser';
| dsbl_localhost | someuser | *q1wqeqweqwe | N | N | N | N | N | N | N | N | N | N | N | N | N | N | N | N | N | N | N | N | N | N | N | N | N | N | | | | | 0 | 0 | 0 | 0 |


То есть, вместо localhost клиенту прописывается Host dsbl_localhost, чтобы он ну никак не мог получить доступ, что же, годный метод. Поиск по интернетам также результатов не дал, видимо, "красивых" решений этой проблемы не существует. Вот даже фич риквест в баг-трекере MySQL: http://bugs.mysql.com/bug.php?id=9736

пятница, 17 сентября 2010 г.

ISPManager + Debian + PHP + виртуальный хостинг = мириады файлов в папке mod-tmp/bin-tmp

Не проходит и недели, чтобы вопрос о том, как победить эту напасть, хоть кто-то не задал на Серче (searchenegines.ru). Итак, вопрос - какого фига они создаются и не удаляются автоматически? Ранее, я поднимал одну из сторону этого вопроса (сколько именно должна храниться сессия) http://phpsuxx.blogspot.com/2010/04/php-debian.html, но там я упустил из виду ряд деталей.

Благодаря одному из наших клиентов (если он меня читает, передаю искреннюю благодарность) я обнаружил такой вот параметр работы PHP сессий:
session.gc_probability = 1

Этот параметр является числителем дроби, которая высчитывает вероятность запуска удаления старых файлов сессий при данном запуске PHP интерпретатора, вся дробь выглядит так:
p = session.gc_probability / session.gc_divisor

То есть, если при данном запуске PHP требуется удалять старые файлы сессий с вероятностью 1/100 (оптимальное дефалтное значение), то значения параметров должны быть 1 и 100 соответственно. Чтобы в свою очередь запретить удаление старых сессий, нужно задать session.gc_probability равным нулю.

Что же мы имеем в стандартной конфигурации свеже установленного Debian с панелью ISPManager? А вот что:

php -i | grep session.gc_
session.gc_divisor => 100 => 100
session.gc_maxlifetime => 1440 => 1440
session.gc_probability => 0 => 0

Внимание вопрос из начала поста - какого хрена? А вот такого (/etc/php5/cgi/php.ini):
; Define the probability that the 'garbage collection' process is started
; on every session initialization.
; The probability is calculated by using gc_probability/gc_divisor,
; e.g. 1/100 means there is a 1% chance that the GC process starts
; on each request.

; 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.gc_divisor = 100

Иными словами, в связи с особенностями системы безопасности в Debian PHP gc был полностью отключен. А что за "strict permissions /var/lib/php5" ? А вот что:
su www-data
domain:~/v001049/data$ ls -la /var/lib/php5
ls: cannot open directory /var/lib/php5: Permission denied
v1:~/v001049/data$ ls -la /var/lib/php5/sess_ffae85888b2698c46af74bcbb36a534f
-rw------- 1 www-data www-data 89 2010-09-17 04:31 /var/lib/php5/sess_ffae85888b2698c46af74bcbb36a534f
domain:~/v001049/data$ cat /var/lib/php5/sess_ffae85888b2698c46af74bcbb36a534f
current_language|i:0;vote_completed|a:0:{}gids|a:1:{i:0;s:4:"1897";}counts|a:1:{i:0;i:1;}v1:~/v001049/data$
domain:~/v001049/data$
domain:~/v001049/data$ rm /var/lib/php5/sess_ffae85888b2698c46af74bcbb36a534f

То есть, в данной папке gc PHP даже теоретически работать не может - ему запретили запрос листинга каталога. Поэтому, сессии удаляются спец-скриптом /etc/cron.d/php5, который пускается от рута по CRON и проблем с правами не имеет.

Но ISPManager ведь создает отдельные папки для сессий клиентов и дает им там полную власть (листинг каталога разрешен!), следовательно, PHP gc будет там работать отлично, поэтому, опцию session.gc_probability можно смело (по крайне мере, если PHP для клиентов работает в режиме FastCGI) приводить в вид:

session.gc_probability = 1

После подобной перенастройки strace по всем PHP процессам легко показывает, что сессии мочатся:
strace -s 1024 -e trace=unlink -f $(pidof php5-cgi | sed 's/\([0-9]*\)/\-p \1/g')
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_fb03780fa60f20c40a9a3a8a653f0a48") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_a6b769c2e42878be628e9eebcff644e1") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_72db961a3a0c427dd2ca206801822eb3") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_2cd999481257e8ddf8fdc564e9b35655") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_81a55680deea55890219ad3ce0e098aa") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_1f00aa57e21437ea859d476da63e4a3c") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_735c6fbe4e76df9cb2aacc704580f934") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_1a5261a2dd852d14c1760efc7315b43d") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_c5e5cff56c2fc56f087e9bfc96c2ae0a") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_74d6c37033f2372b7187f1bffccbda78") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_456c347c477a694f9e85bfdd8cb78919") = 0
[pid 1381] unlink("/var/www/v001218/data/bin-tmp/sess_da4e80b181f5518c282f40c1de2dc3e0") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_ebe77e387b01e9de16f82aa6c35676f3") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_916646b0ed54757bd2c64a2852430af5") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_d2039dbed4dc17b7ad34b93a8820f6cf") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_7563c763ca1e997ff418d40bb945b91b") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_92f0d552abf944226e3c86e1837167b1") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_07a81fe5c04ebedfe2f48a4d55064e9b") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_23af29de2594d854b4264eee09723141") = 0
[pid 1381] unlink("/var/www/xxxxx/data/bin-tmp/sess_7856d53ddb52613410e01495a49d2381") = 0

Вот такая вот проблемка, вот такое вот решение :)

P.S. да, Миш, ты был прав, тут я накосячил поверив чужому аудиту кода PHP.

среда, 25 августа 2010 г.

ISPManager: PHP ошибка доступа

Ошибка возникает при создании сайта с поддержкой PHP (от имени root) для какого-то пользователя, у которого не активирована поддержка PHP. Чтобы избавится от проблемы, нужно пройти в раздел "Пользователи" и активировать пользователю поддержку PHP (например, в режиме "Модуль Апача").

пятница, 20 августа 2010 г.

Быстрое удаление папки bin-tmp при использовании ISPManager

cd /var/www/username/data

yum install -y screen # или apt-get intstall -y screen
install -d -g `stat -c "%G" bin-tmp` -o `stat -c "%U" bin-tmp` -m 700 bin-tmp2
mv bin-tmp bin-tmp-old
mv bin-tmp2 bin-tmp
/etc/init.d/apache2 restart
screen
rm -rf bin-tmp-old

воскресенье, 30 мая 2010 г.

Скрипт для массового добавления www доменов в ISPManager


cat domains.txt | perl -e 'for(<>){ do { chomp; s/^\\s//g; s/\\s+$//g; $_ = lc } for($_); my($d, $ip) = split "\\s+", $_; print "Add $d with $ip to ISPManager\n"; `/usr/local/ispmgr/sbin/mgrctl -m ispmgr wwwdomain.edit domain=$d ip=$ip php=phpmod admin=admin\@mail.ru alias=www.$d sok=ok su=user_name`; }'


В файле domains.txt домены должны быть просто списком в виде:
domain1.ru ip.ad.dr.es
domain2.ru ip.ad.dr.es

Скрипт для массового создания DNS доменов в ISPManager


cat domains.txt | perl -e 'for(<>){ do { chomp; s/^\\s//g; s/\\s+$//g; $_ = lc } for($_); my($d, $ip) = split "\\s+", $_; print "Add $d with $ip to ISPManager\n"; `/usr/local/ispmgr/sbin/mgrctl -m ispmgr domain.edit name=$d ip=$ip ns="ns3.fastvps.ru. ns4.fastvps.ru." sok=ok su=user_namee`; }'


В файле domains.txt домены должны быть просто списком в виде:
domain1.ru ip.ad.dr.es
domain2.ru ip.ad.dr.es

Также есть еще к нему в комплекте скрипт для массового создания DNS поддоменов:
for i in `cat domains.txt | awk '{print $1}'`; do echo $i | perl -e 'my$domain=<>; print $domain; chomp $domain; open my $fl, "<", "types.txt"; for(<$fl>) { chomp; @mas=split "\\s+", $_; print `/usr/local/ispmgr/sbin/mgrctl -m ispmgr domain.sublist.edit plid=$domain sdtype=$mas[1] prio=$mas[2] name=$mas[0] addr=$mas[3] sok=ok`; } ;'; done

Вот пример файла types.txt для Gmail MX:
@ MX 10 ASPMX.L.GOOGLE.COM.
@ MX 20 ALT1.ASPMX.L.GOOGLE.COM.
@ MX 20 ALT2.ASPMX.L.GOOGLE.COM.
@ MX 30 ASPMX4.GOOGLEMAIL.COM.
@ MX 30 ASPMX5.GOOGLEMAIL.COM.
@ MX 30 ASPMX2.GOOGLEMAIL.COM.
@ MX 30 ASPMX3.GOOGLEMAIL.COM.

После запуска скрипта, каждый домен из списка получит такой комплект MX записей.

воскресенье, 16 мая 2010 г.

Критическая уязвимость в расширении ISPManager "mysqldumpupload"

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

Отключать так - настройка сервера, расширения, выбираем mysqldumpupload и нажимаем синюю лампочку на панели справа.

http://forum.searchengines.ru/showthread.php?t=499405

понедельник, 10 мая 2010 г.

ISPManager: May 10 19:30:52 [13216] WARNING Access not allowed ip '95.79.232.217'. Rejected.

Это означает, что юзер заблокировал вход для всех, кроме заданного IP.

Снять ее можно так:
vi /usr/local/ispmgr/var/userconf/ispmgr.[user_name]


И удаляем строчку:
Access xx.xx.xx.xx


Перезапускаем ISPManager:
killall -9 -r ispmgr

суббота, 1 мая 2010 г.

Проверка всех баз данных MySQL / MyISAM на сервере

При наличии панели ISPManager:
mysqlcheck --check --all-databases -u root -p`cat /usr/local/ispmgr/etc/ispmgr.conf | grep Password | awk '{print $2}' | head -n1`
В общем случае:
mysqlcheck --check --all-databases -u root -p
Для фикса надо добавить флаг:  --repair