Slow Fourier Transform

Как я уже упоминал, живет у меня кластер на Gentoo… Если точнее, Gentoo стоит на шести компьютерах из десяти.¹

Кластер он конечно в несколько опосредованном смысле этого слова, потому что ставить OpenMosix мне пока что было упорно лень, машины весьма разнокалиберные, и реально распределение вычислений, когда оно мне надо, идет вручную. Но есть одна задача, в которой кластер проявляет себя во всей красе — это массовый апдейт системы, сопряженный с оргией компиляции всего из исходников для полудюжины разных процессоров с разными флажками.

И есть в этом кластере машина по имени atomsk, тщательно прикидывающаяся DVD-плеером. Он бы прикидывался еще тщательнее, но мне жалко денег на специальный корпус, я наверное лучше закатаю его в тумбочку как-нибудь при случае.

Так вот, несколько месяцев назад я обнаружил, что distcc, т.е. сервер кластерной компиляции, начал валить мне какие-то ошибки, в которых виноват этот самый atomsk. Тогда мне было некогда с ним возиться, так что я просто выкинул его из очереди и забыл, а сейчас, когда пришла пора перебирать Gentoo на основной машине, я решил заняться этим вплотную.

Еще тогда я выяснил, что юзеру distcc Ничего Нельзя. То есть вообще. Сервер запускается — потому что его запускают из-под рута — но после того как он отходит юзеру distcc, он не может сделать вообще ничего, и оглашает кластер жалобными воплями.

Это было странно, но мне лень было разбираться и я его пересобрал. Не помогло. Я пересобрал все остальное, не помогло. Тогда я отложил это еще на месяц.

Сегодня я обнаружил что никому кроме рута на той машине ничего нельзя. Поскольку atomsk работает по сути как tv appliance, то бишь показывает аниме из-под freevo, управляется только с пульта, и полгода я его клавиатуру уже не трогал, никаких других юзеров на нем собственно и нет… окромя distcc. Поэтому я так долго ничего не замечал.

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

За исключением того, что в одном из них посоветовали взглянуть на права на /etc - и на корне тоже.

Я посмотрел на те и другие, но там все было в порядке. И тут я взглянул на права на все остальное…

Мать моя женщина.

С половины директорий в корне слетели куда-то все execute биты. Последствия этого самоочевидны — ни один простой юзер не мог туда войти, не мог загрузить все что надо для логина, и очень от этого страдал, и только один рут под которым все там крутится работал как ни в чем не бывало.

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

1. Еще на одном — Embedix, Amiga 600 как жила под AmigaDOS так и живет, макинтош живет под шестеркой с которой родился, Asus R2H пока живет под своей таблеточной виндой. Моя основная машина дожидается пока авторы ALSA наконец встанут с кресла и напишут драйвер для Audiotrak Maya44 MKII, ну или пока меня отпустит жаба и я куплю для студии что-нибудь другое, и гоняет линюх лишь изредка.↩

I get around 50 bytes of spam per second on the average.

Normally, I use bogofilter as my main spam prevention measure, however, earlier today I ended up having to retrain the thing. Reason? Database grew to over 50 megabytes and choked. It took me quite a while to find out that the reason the database is limited in such a way has nothing to do with bogofilter itself — rather, it inherits the limit Postfix sets for the mailbox size through procmail and imposes it on all files it may access. Which should have been a FAQ for three years by now but wasn’t.

I switched bogofilter from BerkDB to SQLite and the database grew to a whopping 100 megs, but hopefully it will be less of a corruption risk. But with the retrained database, that still wasn’t enough — I get way too much spam and too little legitimate e-mail. About one real message per 5000 or so of spam, so the filter is acting up.

I tried increasing the number of RBL lists checked: relays.ordb.org, dul.ru, sbl-xbl.spamhaus.org, dnsbl.sorbs.net, bl.spamcop.net, combined.njabl.org, but that STILL didn’t stop the flood. I implemented SPF checking, but less domains have it implemented than I’d like, so it didn’t help either.

I guess I can do no better than greylisting with postgrey, but if even that doesn’t help, I’m going to be really, really, really annoyed.

Свежак однако! Очередной червяк, распространяющийся в основном по IM-сетям. Не первый. Но достаточно характерный.

Краткая суть: Все как обычно, “не открывайте файлы неизвестно откуда”. Но в данном случае, файлы лежат на веб-сервере как положено, а вот ссылка на них приходит по AIM. Полученный троян разворачивает бурную деятельность, зацепляется за AIM, и рассылает всему списку контактов самого себя, т.е. является классическим червем на применении социальной инженерии. Поскольку, в отличие от емыла, когда мало ли кто вам писал, в вашем контактлисте в основном лица с которыми вы разговариваете более-менее регулярно и подвоха не ждете, кликают на эту ссылку не в пример чаще чем открывают файлы в емыле.

У нас на Руси такой фокус пройдет со значительно меньшим успехом, в силу того, что довольно широко распространены альтернативные клиенты. Да и самим AIM у нас не пользуется почти никто. Но факт занимателен, а об этом червяке мы еще услышим, если они сервера не придавят.