On Mon, Sep 15, 2003 at 03:58:14PM +0300, Alexandr D. Kanevskiy wrote:
On Mon, Sep 15, 2003 at 03:32:14PM +0300, Paul Arakelyan wrote:
On Mon, Sep 15, 2003 at 12:51:57PM +0300, Alexandr D. Kanevskiy wrote:
On Mon, Sep 15, 2003 at 12:42:27PM +0300, Paul Arakelyan wrote:
Да - там "такая фигня" похоже только в каком-то куске иерархии каталогов. и размеры у файлов таки подозрительно-кратные bolcksize... похоже на некорректный fsck. B-( А что делать/как проверить "правильность" fsck?
B-( а держать ядро с потенциальным local root exploit не стремно ? опять же - сейчас уже развелось довольно много автоматических червячков троянчиков которые замечательно себя расселяют через необновленные apache, bind, ssh и прочие опасные сервисы. Там эти сервисы сильно не поменяешь - они в виде бинарников и заточены под надобности хостинга (короче - ensim webpliance), и руками туда лезть чревато появлением "совсем странных" граблей. А если не лезть - то ещё хуже бывало :( - что sendmail с отсутствием maxdaemonchildren, что apache с MaxClients 150 и PHP/FP/mod_куча_всего.
А при замене ядра - ничего в системе пересобирать не понадобится (типа top/ps/...)? нет. пользуйся всеми обновлениями что рекомендует vendor твоей операционной системы и будет тебе щастя. :) Не получится "в лоб" - там ситуация выглядит как "на стандартный redhat накатываются куча rpm'ов имени ensim software" - и в случае дырок в своём софте ensim просто выпускает апдейт - так оно всё и живёт на куче патченого софта, типа sendmail-8.11.6.
И какой-нить вариант в стиле "с этим не завелось, пробуем старое" есть? да есть. ставишь ядро не по rpm -U, а по rpm -i вторым. тогда остается выбор. но правда придется позвонить людям и попросить что при перезагрузке выберите пожалуйста второй пункт меню. Если я его так поставлю - то оно автоматом загрузиться всё же попытается с нового?
2. прогони руками fsck на разделе. Его можно куда-нить в /etc/rc запихнуть и fsck -y ? ну rc.sysinit можно похачить чуток. кажется разобрался :).
Или лучше раз 20 reboot? Или куда чего-то написать, чтоб fsck каждый раз чекало? мож tune2fs тебе поможет ? :) /dev/sda2 on / type ext3 (rw,usrquota,grpquota) я так понял, что по ней вообще непонятно когда fsck проезжает.
3. посмотри lsattr'ом эти файлики куда писать не можешь. возможно там lsattr рисует одни ------ ну значит все хорошо. Лучше б было плохо ;).
Но туда и apache пущенный от рута не пишет(дата меняется на глазах - и всё). И в этом chroot никаких страшных cgi's нету. эта, а убить файл и создать новый с таким же именем ? или и для новых файлов такие глюки ? Фухх - решил проблему - таки новым файлам везёт больше. В данном случае была "интересная" нагрузка - cgi, делающий echo >>file - и таких их одновременно летало штук 40, наверно (стоит squid->apache с лимитом запросов одновременных)
fsck какие-то из служебных типа immutable битиков на файл выставил. Я вот думаю, может это что-то проломали там (а чего ещё ждать от юзеров, которым в руки дали CGI (хоть оно и suexec и chroot) а может ручки админа ? за всем следить надо. не бывает такого что живет Надо - только когда его становится неадекватно дофига... Тяжеловато.
само по себе неограниченное количество времени. В плане софтовых конструкций - правильные вещи живут. По крайней мере, "довольно долго", хотя нагрузки тут сравнивать не стоит наверно...
Бо как-то странно - тазик вроде ж всё время (каждый день) нормально ребутится, и в тот день ничего особо не видать странного... ну rpm -Va в руки и смотрите что менялось в системе. Что-то много оно всего написало - куда смотреть на тему "что это всё такое?". А с каких пор оно это проверяет - с момента последнего запуска?
-- Best regards, Paul Arakelyan. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message