08.21.08
some spamhost statistic.
Кол-во reject’ов по блок-листам на одном из серверов:
bash-2.03# wc -l /tmp/blocked
6704432 /tmp/blocked
И уники:
bash-2.03# cat /tmp/blocked | sort | uniq | wc -l
227667
Curiouser and curiouser!
Кол-во reject’ов по блок-листам на одном из серверов:
bash-2.03# wc -l /tmp/blocked
6704432 /tmp/blocked
И уники:
bash-2.03# cat /tmp/blocked | sort | uniq | wc -l
227667
Короткая заметка, как же все-таки их подружить без кучи костылей, типа вспомогательных скриптов:
http://teichman.org/blog/2006/02/screen_and_ssha.html
Только setenv, как и всякие set/typeset/declare не является внешней вызываемой программой, а внутренней командой интерпретатора. Во всяком случае which о них ни во freebsd, ни в ubuntu не знает. Поэтому именно такой вариант, как у автора, у меня не работает. Самое простое решение - разместить определение переменной SSH_AUTH_SOCK не в .screenrc, а в .bash_profile, ну или в соответствующем конфиге для Вашего шелла. Плюс, хотелось бы отметить, что ssh-add будет работать только в соответствующем окне screen, где он был запущен, так как нигде больше нет информации о SSH_AGENT_PID
Раньше роль страшного пугала для пользователей и хостеров из борцов со спамом представлял sorbs, со своей неадекватной политикой включения и выключения хостов в свои списки. В последние пару лет его уверенно потеснил spamhaus. Помимо широко известного скандала с Мажордомо, когда один неадекватный регистратор Godaddy рубанул кучу доменов клиентов Мажоржомо по жалобе spamhaus, они гадят и в более маленьком масштабе:
http://www.spamhaus.org/sbl/sbl.lasso?query=SBL65965
Вот и пара наших серверов попала “заодно” вместе с подсеткой /24 за то, что в этой подсети располагался dns сервер комапнии nameself.com, которая поддерживает (only by dns) домен (2 штука), которые рекламировались спамом. Впрочем, /24 не предел. Многие пользователи colocation у компаниии RTCOMM помнят еще блок по /16 от того же spamhaus…
Пакет rinse (версии 0.9x) в ubuntu 8.04 содержит некоторое кол-во ошибок, которые не позволяют через xen-tools установить centos в качетсве domU ОС. Если нет желания копаться во скриптах, можно просто поставить самую новую версию с сайта разработчика. Правда, package для ubuntu там отсутствует, но вполне подойдет дебиановский вариант http://apt.steve.org.uk/etch/pool/main/r/rinse/. Или посмотреть в https://launchpad.net/ubuntu/+source/rinse , там какие-то фиксы были, также, как и ссылки на debian-unstable. Заодно имеет смысл в /etc/rinse/rinse.conf выбрать зеркало поближе, например http://mirror.yandex.ru/centos/4.6/os/i386/CentOS/
+поменять актуальную версию centos на 4.6 или 5.2, в зависимости от того, что ставите. А также добавить необходимое в список скачиваемых пакетов. С учетом установки из скриптов ssh и нескольких зависимостей, вероятно, не упомянутых в общем списке, кол-во пакетов получилось 96 против 75, упомянутых в конфигах rinse.
dom0# grep -i ‘^[a-z]’ /etc/rinse/centos-5.packages | wc -l
75
domU# rpm -qa | wc -l
96
Быстрый способ узнать, есть ли поддержка технологий AMD-V ил Intel-VT:
# grep -Eo ’svm|vmx’ /proc/cpuinfo
svm
svm
В процессе неспешного скриптования наткнулся на неприятную особенность баша. И в очередной раз, чертыхаясь, пожалел о том, что не стал писать программу на perl. Не то, чтобы я знаю его очень хорошо, но по-крайней мере таких ляпов там бы не было.
Дано:
# include current rbl config
if [ -f ${rblconf} ]; then
. ${rblconf}
else
echo “fail to read ${rblconf} file!”
exit 1
fi
Результат:
$ ./reposync chkr lupdate
./reposync: line 42: .: filename argument required
.: usage: . filename [arguments]
…
Сначала не мог понять, где же мой косяк. Выяснилось, что в процессе редактирования я случайно удалил строчку с определением переменной $rblconf. Почему-то bash считает нужным при файловых проверках на несуществующих переменных возвращать истину, а не ложь. Бред. Так что мы имеем вот такое:
$ if [ -f $fdxxdxafdsfdl ]; then echo “stupid, but ok”; else echo “variable unset or file does no exist”;fi
stupid, but ok
Самое ужасное, что это скорее всего не бага, а фича. Нужно будет спросить у знакомого гуру в программировании, “что здесь собственно происходит?”
Оказывается gnu сейчас бОльшей частью использует git. Не cvs/svn, а именно git. Не смотря на двойственное отношение к Linus’у и его детищу
http://git.savannah.gnu.org/gitweb/
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=shortlog;h=v6.12;pg=1
Заметил, что почему-то ко мне в блог много приходит по запросам относительно postfix с авторизацией пользователей через dovecot sasl. Ума не приложу что тут сложного, но наверно стоит общий образец нарисовать. Postfix совсем не обязательно компилировать с поддержкой именно dovecot sasl и держать в системе хедеры и прочая от dovecot для этого. Sasl как-никак стандарт и начиная с какой-то версии postfix, по-моему с 2.3 можно просто указать тип sasl в
main.cf. По-большему счету вот все, что нам нужно:
/etc/postfix/main.cf
smtpd_sasl_auth_enable=yes
broken_sasl_auth_clients = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
/etc/dovecot/dovecot.conf
auth default {
mechanisms = PLAIN LOGIN DIGEST-MD5 CRAM-MD5
passdb sql {
args = /etc/dovecot/dovecot-sql.conf
}
userdb prefetch {
}
# needed for lda
userdb sql {
args = /etc/dovecot/dovecot-sql.conf
}
user = authdovecot
# It’s possible to export the authentication interface to other programs:
socket listen {
master {
path = /var/run/dovecot/auth-master
mode = 0600
user = vmail
}
client {
path = /var/spool/postfix/private/auth
mode = 0660
user = postfix
group = postfix
}
}
}
Из конфига dovecot важно вобщем-то только часть про client{}
Принесла мне хорошая девушка пару дисков dvd с кучей записанных фоток. Один диск читался очень долго и нудно, с множеством ошибок, второй не читался вобще. С первым все решилось довольно просто. Монтировался нормально, и далее просто копировались файлы cp с ключом force или rsync. Потери составили около 30Mb на 4,xGb. Причем процесс шел довольно шустро, сравнительно с теми часами, которые это занимало в windows. А вот со вторым все было плохо. Диск не монтировался. К счастью, nerolinux видел и записанную дорожку и даже названия папок/файлов с указанием для последних занимаемого места. Стал смотреть, что мы имеем для восстановления такого чуда. В первую очередь в голову естественно пришел dd для считывания данных в iso образ. Но увы и ах, несмотря на явным образом заданный объем для считывания, а также опцию conv=noerror процесс заканчивался копированием двух пустых килобайт. Несмотря на указание bs=1M и seek=xx, skip=xx. У диска, судя по всему, было повреждено начало, поэтому дальше этих двух килобайт процесс в принципе не шёл. Чуть позже нашлась совершенно замечательная по описаниям утилита - ddrescue. Которая даже в репозитариях ubuntu есть. Среди важных отличий от dd, указывалась возможность действительно игнорировать ошибки чтения, забивать нечитаемые сектора в output нулями и даже reverse read. То, чего мне первое пришло в голову искать с dd, но чего в оном не оказалось. И тем не менее, та же история. Читаем первые два килобайта и умираем. Уж не знаю, может быть опция -r работает не так, как я об этом полагал. Стал думать, а нельзя ли это дело еще как нибудь на уровне raw доступа считать, и уже дальше разбираться с образом. На http://openkazan.info/node/1009 нашел нужные опции к cdrdao
cdrdao read-cd –read-raw –device /dev/sr0 dump.toc
которые при желании находятся в мане. Не выходит каменный цветок.
/dev/scd0: _NEC DVD_RW ND-3520A Rev: 1.04
Using driver: Generic SCSI-3/MMC - Version 2.0 (options 0×0000)
Reading toc and track data…
ERROR: Cannot read disk toc.
Может быть покрутив что-нибудь с опциями и можно было сделать, но эти опции не просматривались в досягаемом материале. То, что просмотр дорожки под nerolinux показывал вполне себе не пустой диск, а какие-то данные, если перемотать чуть-чуть вперед - заставляло меня продолжать поиск.
В погоне за результатом опустился до виндовых программ, запускаемых из под wine (0.9.60 под amd64). ОС Windows сама у меня на компьютере некоторое время соседствовал (для игр) c Linux, но года три назад перестала отягощать винчестер совсем. Посему это воспринялось мной как некое отступление. Всегда предпочитаю искать нативное решение и в большинстве случаев такие решения находились. Как практика показывала, они оказывались даже лучше. Но здесь мне нужен был результат, и желательно быстрый. Погуглив, нашел Cdroller и Cdcheck, которые принципиально не дружили с wine. Их хватило только на установку. Результата я добился в итоге с помощью (да, пусть это будет некоторой рекламой этой хорошей программе) Diskinternals CD-DVD recovery. Её совсем не смутило, что запуск был из под вайна. Спокойно нашла привод и прочитала, по-моему, практически все файлы. На данный момент уже восстановлена бОльшая их часть:
$ du -hs /home/media/temp/recover
3,7G /home/media/temp/recover
Уверен, что под windows есть и другие замечательные программы, которые позволят с легкостью решить такую задачу и которые даже могут быть freeware в отличии от названной. Но будут ли они дружить с wine - не знаю. Искренне надеюсь, что все-таки со временем найдутся нативные решения под линукс. Мимо которых скорее всего я просто прошел. Абсолютно не принципиально, будут ли они консольные или гуевые. Главное, чтоб были.
Несмотря на отсутствие тела, сцены преступления и каких-либо существенных улик, суд присяжных посчитал Ганса Рейзера виновным в убийстве первой степени. Очень печально.
http://blog.wired.com/27bstroke6/hans_reiser_trial/#49144716
Все это мне напоминает “Постороннего” Камю, где судили не даже не за убийство, а за поведение, которое не соответствовало
общепринятой морали и т.п. Только в данном случае доказательств
в убийстве не было. А основная роль в вердикте, так же, как и там - неприязненное отношение судей и присяжных к обвиняемому.