Ну вот - только написал, что пингвины со мной не дружат - как обнаружил странную вещь: apache вдруг перестал писать в log files, и cgi'ка простенькая, типа echo >>somefile - аналогично. Время на файлах апдейтится, но более ничего не происходит. Да, если сказать от рута echo >>file и file существует - то результат аналогичный. Такая фигня произошла непонятно почему уж пару дней как... xxxxxxxxxxxx.net - - [14/Sep/2003:10:18:43 -0400] "GET /xxxxxxxxxxx?xxxxx HTTP /1.0" 200 43 "http://xxxx.com/cgi-b И ВСЁ! :(. Торба - более в файл ничего не попадало - а время доступа апдейтится вполне адекватно. df показывает тучу гигов свободно, другие файлы - вроде всё ОК. То есть - в некоторые файлы почему-то нифига не записывается. У некоторых файлов "очень странный размер" - типа 16384/65536 байт - может это fsck что-то наворотило? reboot положения не исправил. Тазик ребутится по cron (или вешается по рандому :(. dual p2/2GB ecc ram), за автоапдейты всякие - вроде есть, но точно не знаю - иногда что-то руками апдейтить приходилось... Linux 2.4.7-10smp #1 SMP Thu Sep 6 17:09:31 EDT 2001 i686 unknown BASH_VERSINFO=([0]="2" [1]="05" [2]="8" [3]="1" [4]="release" [5]="i386-redhat-l inux-gnu") BASH_VERSION=$'2.05.8(1)-release' -- 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
On Mon, Sep 15, 2003 at 12:42:27PM +0300, Paul Arakelyan wrote: > Ну вот - только написал, что пингвины со мной не дружат - как > обнаружил странную вещь: > И ВСЁ! :(. Торба - более в файл ничего не попадало - а время доступа > апдейтится вполне адекватно. df показывает тучу гигов свободно, > другие файлы - вроде всё ОК. > То есть - в некоторые файлы почему-то нифига не записывается. > У некоторых файлов "очень странный размер" - типа 16384/65536 байт - > может это fsck что-то наворотило? возможно. > reboot положения не исправил. > Тазик ребутится по cron (или вешается по рандому :(. dual p2/2GB ecc ram), > за автоапдейты всякие - вроде есть, но точно не знаю - иногда что-то руками > апдейтить приходилось... > > Linux 2.4.7-10smp #1 SMP Thu Sep 6 17:09:31 EDT 2001 i686 unknown > BASH_VERSINFO=([0]="2" [1]="05" [2]="8" [3]="1" [4]="release" [5]="i386-redhat-l > inux-gnu") > BASH_VERSION=$'2.05.8(1)-release' 1. проапдейте ядро. RH уже штук 5 обновлений делал. и делал он их не просто так "от фонаря". 2. прогони руками fsck на разделе. 3. посмотри lsattr'ом эти файлики куда писать не можешь. возможно там fsck какие-то из служебных типа immutable битиков на файл выставил. -- With best regards, Alexandr Kanevskiy. ISP Inter-Don. CTO AK2240-RIPE, AK2-6BONE =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
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: > > > То есть - в некоторые файлы почему-то нифига не записывается. > > У некоторых файлов "очень странный размер" - типа 16384/65536 байт - > > может это fsck что-то наворотило? > возможно. Да - там "такая фигня" похоже только в каком-то куске иерархии каталогов. и размеры у файлов таки подозрительно-кратные bolcksize... > > reboot положения не исправил. > > > Тазик ребутится по cron (или вешается по рандому :(. dual p2/2GB ecc ram), > > за автоапдейты всякие - вроде есть, но точно не знаю - иногда что-то руками > > апдейтить приходилось... > > > > Linux 2.4.7-10smp #1 SMP Thu Sep 6 17:09:31 EDT 2001 i686 unknown > > BASH_VERSINFO=([0]="2" [1]="05" [2]="8" [3]="1" [4]="release" [5]="i386-redhat-l > > inux-gnu") > > BASH_VERSION=$'2.05.8(1)-release' > 1. проапдейте ядро. RH уже штук 5 обновлений делал. и делал он их не просто так "от фонаря". Стрёмно - тазик стоит за океаном, к нему "кто-либо" добираться будет часа 2, квалификации его хватило, чтоб тот redhat из коробки поставить и "ensim hosting software" аналогично, ну а далее меня поставить перед фактом - а в линуксах я понимаю явно маловато - с закрытыми глазами в случае чего врядли разберусь. А оно ж SMP - вдруг и с этим какие-то грабли возникнут. А при замене ядра - ничего в системе пересобирать не понадобится (типа top/ps/...)? И какой-нить вариант в стиле "с этим не завелось, пробуем старое" есть? > 2. прогони руками fsck на разделе. Его можно куда-нить в /etc/rc запихнуть и fsck -y ? Или лучше раз 20 reboot? Или куда чего-то написать, чтоб fsck каждый раз чекало? > 3. посмотри lsattr'ом эти файлики куда писать не можешь. возможно там lsattr рисует одни ------ Но туда и apache пущенный от рута не пишет(дата меняется на глазах - и всё). И в этом chroot никаких страшных cgi's нету. > fsck какие-то из служебных типа immutable битиков на файл выставил. Я вот думаю, может это что-то проломали там (а чего ещё ждать от юзеров, которым в руки дали CGI (хоть оно и suexec и chroot) Бо как-то странно - тазик вроде ж всё время (каждый день) нормально ребутится, и в тот день ничего особо не видать странного... -- 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
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: > > > > > То есть - в некоторые файлы почему-то нифига не записывается. > > > У некоторых файлов "очень странный размер" - типа 16384/65536 байт - > > > может это fsck что-то наворотило? > > возможно. > Да - там "такая фигня" похоже только в каком-то куске иерархии каталогов. > и размеры у файлов таки подозрительно-кратные bolcksize... похоже на некорректный fsck. B-( > > > reboot положения не исправил. > > > > > Тазик ребутится по cron (или вешается по рандому :(. dual p2/2GB ecc ram), > > > за автоапдейты всякие - вроде есть, но точно не знаю - иногда что-то руками > > > апдейтить приходилось... > > > > > > Linux 2.4.7-10smp #1 SMP Thu Sep 6 17:09:31 EDT 2001 i686 unknown > > > BASH_VERSINFO=([0]="2" [1]="05" [2]="8" [3]="1" [4]="release" [5]="i386-redhat-l > > > inux-gnu") > > > BASH_VERSION=$'2.05.8(1)-release' > > 1. проапдейте ядро. RH уже штук 5 обновлений делал. и делал он их не просто так "от фонаря". > Стрёмно - тазик стоит за океаном, к нему "кто-либо" добираться будет > часа 2, B-( а держать ядро с потенциальным local root exploit не стремно ? опять же - сейчас уже развелось довольно много автоматических червячков троянчиков которые замечательно себя расселяют через необновленные apache, bind, ssh и прочие опасные сервисы. > квалификации его хватило, чтоб тот redhat из коробки поставить > и "ensim hosting software" аналогично, ну а далее меня поставить перед > фактом - а в линуксах я понимаю явно маловато - с закрытыми глазами > в случае чего врядли разберусь. А оно ж SMP - вдруг и с этим какие-то > грабли возникнут. > А при замене ядра - ничего в системе пересобирать не понадобится (типа > top/ps/...)? нет. пользуйся всеми обновлениями что рекомендует vendor твоей операционной системы и будет тебе щастя. :) > И какой-нить вариант в стиле "с этим не завелось, пробуем > старое" есть? да есть. ставишь ядро не по rpm -U, а по rpm -i вторым. тогда остается выбор. но правда придется позвонить людям и попросить что при перезагрузке выберите пожалуйста второй пункт меню. > > 2. прогони руками fsck на разделе. > Его можно куда-нить в /etc/rc запихнуть и fsck -y ? ну rc.sysinit можно похачить чуток. > Или лучше раз 20 reboot? > Или куда чего-то написать, чтоб fsck каждый раз чекало? мож tune2fs тебе поможет ? :) > > 3. посмотри lsattr'ом эти файлики куда писать не можешь. возможно там > lsattr рисует одни ------ ну значит все хорошо. > Но туда и apache пущенный от рута не пишет(дата меняется на глазах - и всё). > И в этом chroot никаких страшных cgi's нету. эта, а убить файл и создать новый с таким же именем ? или и для новых файлов такие глюки ? > > fsck какие-то из служебных типа immutable битиков на файл выставил. > Я вот думаю, может это что-то проломали там (а чего ещё ждать от > юзеров, которым в руки дали CGI (хоть оно и suexec и chroot) а может ручки админа ? за всем следить надо. не бывает такого что живет само по себе неограниченное количество времени. > Бо как-то странно - тазик вроде ж всё время (каждый день) > нормально ребутится, и в тот день ничего особо не видать странного... ну rpm -Va в руки и смотрите что менялось в системе. -- With best regards, Alexandr Kanevskiy. ISP Inter-Don. CTO AK2240-RIPE, AK2-6BONE =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
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
On Mon, Sep 15, 2003 at 08:16:40PM +0300, Paul Arakelyan wrote:
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_куча_всего.
Вообще-то тема изначально - жуткий offtopic :( Я имел дело с машиной на rackshack примерно с тем же набором - redhat + ensim. Каша ещё та. Смысл манипуляций сводится к поиску обновлений и связанных с ними граблей на парочке форумов. http://forums.rackshack.net У тебя также должен быть RS account login для доступа на http://www.rackshack.net/support (если твоя машина тоже на RS) Ну и здесь: http://www.ensim.com/support Читаешь всё, что народ пишет по поводу затыкания дыр и граблей, возникающих в процессе. Особое внимание уделяешь DNS (у ensim управление DNS совсем конченное, с ним можно иметь дело, но нужен большой навык :) и тому, чтобы ничего не прикончить в MySQL и PostgreSQL базах. Ну и затыкаешь :) А вообще - сочувстую :) То ещё занятие... Regards, -- Igor A. Karpov phone: +380(44)238-0624 JID:jc@mash.minjust.gov.ua Unix System Administrator You can't judge a book by its movie. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
participants (3)
-
Alexandr D. Kanevskiy -
Igor Karpov -
Paul Arakelyan