Тим, хто користується spamassassin для фільтрування спаму (хоча я от планую переповзати на dspam потихеньку), знадобиться такий скрипт для автоматичного навчання:

#!/usr/bin/env bash
IFS=$'\n'
spooldir="/var/spool/virtual"
domains=`ls -1 $spooldir`
for domain in $domains
do
        users=`ls -1 $spooldir/$domain`
        for user in $users
        do
                echo Examining $user@$domain INBOX...
                /usr/bin/sa-learn --no-sync --ham $spooldir/$domain/$user/{cur,new,tmp}

                dirs=`find $spooldir/$domain/$user/ -maxdepth 1 -type d -name '.*'`
                for i in $dirs
                do
                        dir=`basename "$i"`
                        [[ "$dir" == ".Junk" ]] && continue
                        [[ "$dir" == ".Viruses" ]] && continue
                        echo Examining $user@$domain "$dir"...
                        /usr/bin/sa-learn --no-sync --ham $spooldir/$domain/$user/"$dir"/{cur,new,tmp}
                done

                if [[ -d "$spooldir/$domain/$user/.Junk" ]]
                then
                        echo Examining $user@$domain Junk...
                        /usr/bin/sa-learn --no-sync --spam $spooldir/$domain/$user/.Junk/{cur,new,tmp}
                        echo done.
                fi
        done
done

echo Syncing...
/usr/bin/sa-learn --sync
echo done.

Головне — заставити користувачів перший час не лінуватися вручну сортувати спам-не спам.

5-го числа цього місяця там же, де й завжди, пройшла конференція OSDN 2013.

Цього року явно щось не так було з організацією — взагалі не було реєстрації (а як же фірмові блокноти, ручки й бейджики, а ще дівчата на ресепшні???), відкриття конференції, здається, затрималося, у будівлі ТСОУ чергувала якась божевільна бабця, а ще було дуууже холодно. Шигорін прямо на сцені сам одягав доповідачів :).

Доповіді були різні, в основному, оглядові, звісно. Про відвертий треш не хочу згадувати, а от Маркелова з OpenShift’ом, Радецького з Asterisk’ом, Маржана з «Покращенням…», Шаматріна з Perl’ом, ну і, звісно, Костюка з оцінюванням GUI хочеться виділити окремо. Цікаво було.

На перервах із задоволенням слухали Фоміна, який тепер пиляє десктопну ROSу.

Жаль, що не було купи цікавого народу, як київських, так і не київських, наприклад, Злобіна.

Звісно, хочеться, щоб у наступному році сталося щось типу такого, як у 2007-му: серйозна виставка, доповіді у два потоки, ТПП і купа народу. Інакше конференції OSDN почнуть набридати.

Ну і невеликий фотозвіт від мене тут. Освітлення там було паскудне, фоткав на ISO 3200, тому про якість нічого мені не кажіть.

Астеріск версії 1.8, якраз той, що в серверній Убунті, на жаль, не містить security framework (його додали пізніше, чи то в 10-й, чи то в 11-й версії). Усе, що мені поки потрібно від security framework — це IP-адреси брутфорсерів, щоб їх банити iptables’ом, але які 1.8 просто не показує.

Але для мого випадку проблема може вирішуватися інакше.
Читати далі »

I had a discussion today with someone who maintained with confidence that “If Linux were as popular as Windows, we’d be seeing just as many viruses and just as much malware for it as we see now for Windows”.

While that argument might hold true for desktop users, to an extent, the focus of the discussion was essentially (from his point of view) that “Linux is no more secure than Windows”, fundamentally.

Which is false. When I pointed this out, it was dismissed as simply my opinion, but I believe that he’s stuck in a logical fallacy in this assertion.

Звідси.

Є невелика клієнтська мережа на десяток активних пристроїв, які потрібно моніторити на предмет доступності. Піднімати для цього Нагіос/Ісінгу або Заббікс не дуже хотілося, тим більше, що мережа доволі статична. Так народився цей скрипт.
Читати далі »

Звісно, класикою жанру вважається bash, але хто я такий, що просто ставити й використовувати те, що використовує більшість народу :)?

Дуже довго я сидів на zsh, і не можу про нього нічого сказати поганого — навпаки, дуже зручна й потужна штука.

Але кілька місяців тому я відкрив для себе fish із його кольоровою підсвіткою команд і зручною історією, і тепер використовую його. Не знаю, чи надовго це, але принаймні *поки* зручно.

Налаштований мною роутер (усе серйозно — VLAN’и, шейпінг etc) на Лінуксі періодично валив мережу через скидання мережевої карти. Типу, зависала вона.

Aug 8 11:38:25 atlantis kernel: [240509.881537] e1000e 0000:00:19.0 eth0: Detected Hardware Unit Hang:
Aug 8 11:38:25 atlantis kernel: [240509.881537] TDH <c3>
Aug 8 11:38:25 atlantis kernel: [240509.881537] TDT <d0>
Aug 8 11:38:25 atlantis kernel: [240509.881537] next_to_use <d0>
Aug 8 11:38:25 atlantis kernel: [240509.881537] next_to_clean <c1>
Aug 8 11:38:25 atlantis kernel: [240509.881537] buffer_info[next_to_clean]:
Aug 8 11:38:25 atlantis kernel: [240509.881537] time_stamp <10396ec44>
Aug 8 11:38:25 atlantis kernel: [240509.881537] next_to_watch <c3>
Aug 8 11:38:25 atlantis kernel: [240509.881537] jiffies <10396eed3>
Aug 8 11:38:25 atlantis kernel: [240509.881537] next_to_watch.status <0>
Aug 8 11:38:25 atlantis kernel: [240509.881537] MAC Status <40080083>
Aug 8 11:38:25 atlantis kernel: [240509.881537] PHY Status <796d>
Aug 8 11:38:25 atlantis kernel: [240509.881537] PHY 1000BASE-T Status <7800>
Aug 8 11:38:25 atlantis kernel: [240509.881537] PHY Extended Status <3000>
Aug 8 11:38:25 atlantis kernel: [240509.881537] PCI Status <10>

Драйвер — e1000e. Так от, якщо таке трапляється, то лікується воно (принаймні, на ядрах 3.8) отак:

ethtool -K eth0 tso off

По-хорошому, треба б надіслати багрепорт, але рішення я ж нагуглив з уже надісланого багрепорта, а чого це не виправили — не знаю.

Довелося тут підняти критичний до затримок тунель, через який працюватиме купа народу з термінальним сервером. Виявилося, що затримка пакетів у такому тунелі гуляє, як остання дівка, причому, значення дуже сильно відрізняються від пінгів зовнішньої білої адреси. Іноді різниця доходить до 5 разів у гірший бік. Піки спостерігаються, коли хтось працює, а якщо канал не завантажено, то значення перебувають у межах норми. Моніторинг завантаженості каналу показав… 2%. Щось тут не так.

Рішення знайшлося через гугл. У конфіг сервака потрібно додати опцію tcp-nodelay, яка каже, що пакети будуть відправлятися негайно, а не з певною затримкою для агрегації. Після цього пінг нормалізувався. Причому, він став меншим за пінг до білої адреси О_о. Мабуть, це приколи мережевого стека Лінукса й Xen’а, оскільки термінальний сервер сидить за гентушним NAT’ом.

Компресію я також про всяк випадок вимкнув. Кажуть, також впливає на пінг.

Через дибілкуватість із сортуванням числових версій арчевський repo-add вважає, що 3.9 новіше за 3.10. Лікується це так:

repo-add pf-repo.db.tar.gz `find . -name "*.pkg.tar.xz" | sort -V`

З деб-пакетами все простіше:

dpkg-scanpackages -m pf /dev/null | gzip -9c > pf/Packages.gz

Довготривалі команди, які треба виконувати у screen через ssh, запускаються отак:

screen -U -d -m -S build-helper ./build-helper-worker.sh

Тут скрипт build-helper-worker.sh якраз і містить виклики через ssh. Наприклад:

#!/usr/bin/env bash

ver="pf-3.10"
ssh arch /home/pf/build-helper-chrooter.sh $ver
ssh debian /home/pf/build-helper-chrooter.sh $ver
ssh ubuntu /home/pf/build-helper-chrooter.sh $ver

Скрипт build-helper-chrooter.sh — це вже штука, яка запускає компіляцію в chroot’і:

#!/usr/bin/env bash

sudo chroot /home/pf/chroots/amd64 su pf -c "TERM=xterm /home/pf/build-helper-1.sh $1"
sudo chroot /home/pf/chroots/i686 su pf -c "TERM=xterm /home/pf/build-helper-1.sh $1"

А build-helper-1.sh — скрипт, специфічний для кожного chroot’а. Наприклад:

#!/usr/bin/env bash

cd /home/pf/kernel/pf-kernel
rm *.xz
git pull
echo $1
git checkout $1
scripts/build-pf.sh arch

Це все маленькі трюки із власноруч склепаної білд-ферми для pf-kernel.