Какие есть вьюверы для ls -lR-списков кроме mc? Нашел какой-то заброшенный и не собирающийся gtk-lsviewer - https://launchpad.net/gtk-lsviewer - что есть еще?

[18:24:28] <rain> какая-то бага в Audacity... Меняю частоту дискретизации дорожки - меняет и обрезает дорожку

[18:30:08] <rain@mws> открыл произвольный двухканальный FLAC, делаю конвертацию с 44100 -> 176400, время меняется 1-42-160 -> 1-41-424

[18:34:39] <rain@mws> 1-41-717 при 96000

[18:34:53] <rain@mws> а проверьте кто-то у себя

[18:39:36] <rain> рецепт: открываем какой-нибудь flac (в принципе, пофиг что). Щелкаем мышей на дорожке, жмем End - курсор становится в позицию конца дорожки. На счетчике внизу можно увидеть точное время дорожки. Идем в «Дорожки» - «Сменить частоту дискретизации дорожки», вводим, например, 96000, ждем, пока сконвертирует, снова щелкаем на дорожке и нажимаем End. Длительность получается другой.

[18:40:21] <rain> rain@acnote:~$ apt-cache policy audacity

audacity:

Установлен: 1.3.12-7.4

[18:42:01] <rain> http://rain.linuxoid.in/fileupload/screenshots/audacity_bug_01.png - пример. Один канал сконвертился и стал короче, второй в процессе.

Только у меня такое вылазит?

Собственно, сабж. В связи с событиями последних суток вокруг меня, http://hvosting.ua и домена linuxoid.in (да и jabberworld.info тоже перенесу, раз уж такая пьянка пошла) - к какому адекватному регистратору на Украине можно податься, с нормальным сервисом и различными вариантами оплаты услуг?

А чего никто новость не оформит? Новая версия же - http://www.opennet.ru/opennews/art.shtml?num=29119

ЗЫ: Knoppix уже не тот :(

Качаю@раздаю

Вариант 1: не передаем команду:

root@goro:~# seq 101 111 | while read i ; do vzctl exec $i ; done
No command line given for exec
No command line given for exec
*** etc ***

цикл выполняется.

Вариант 2: пробуем что-то, кроме exec:

root@goro:~# seq 101 111 | while read i ; do vzctl status $i ; done
CTID 101 exist mounted running
CTID 102 exist mounted running
CTID 103 exist mounted running
*** etc ***

цикл выполняется.

Вариант 3: пробуем for:

root@goro:~# for i in `seq 101 111` ; do vzctl exec $i id ; done
uid=0(root) gid=0(root) groups=0(root)
uid=0(root) gid=0(root) groups=0(root)
uid=0(root) gid=0(root) groups=0(root)
*** etc ***

Цикл выполняется.

А теперь, собственно, вопрос:

root@goro:~# seq 101 111 | while read i ; do vzctl exec $i id ; done
uid=0(root) gid=0(root) groups=0(root)
root@goro:~#

root@goro:~# seq 101 111 | while read i ; do vzctl exec $i id && echo blah $HOSTNAME ; done
uid=0(root) gid=0(root) groups=0(root)
blah goro
root@goro:~#

команды после vzctl выполняются, т.е., он завершается успешно и не break'ает цикл.

А, да, Debian Squeeze

Пруф: http://www.kernel.org/

Чейнджлоги в процессе создания :)

Hello, I found security bug in D-Link DIR-300 wireless router. It can be used to bypass authentication mechanizm by attacker with access to web interface.

Пруф: http://securityvulns.ru/Zdocument119.html

Самое веселое:

I reported it to D-Link but they are not replying for my emails. According to other D-Link security holes and their status I think that they won't reply, so I decided to write about it here.

--------

- Information sent to vendor 07.08.2010

- No response

- Information resended to vendor 07.31.2010

- No response from vendor

Dlink такой Dlink

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

- При полном заряде все батареи находятся под зарядным напряжением (Uз), которое гарантированно выше (14-15 В), чем напряжение на неподключенном аккумуляторе (13-13,5 В) (Uxx), следовательно, определяющим источником энергии является именно зарядное устройство ЮПСки.

- При переходе на работу от аккумуляторов ЮПСка становится основным потребителем энергии, просаживая напряжение на батареях до значения ниже их номинального уровня (например, 12,8 В, Up), при этом не важно, какой это был бы уровень Uxx - он все равно выше, чем Up, т.е., опять-таки батареи не влияют друг на друга. По-идее, можно подключать впараллель и батареи разной емкости - с каждой будет спрашиваться по возможностям, малые батареи хоть немного, но будут разгружать большие, а большие не будут давать потреблять нагрузкой большой ток с малых.

- По достижению уровня разряда (10,5 В) на всех батареях ЮПСка отключается.

- При заряде происходит то же, что и в п. 1 - основным источником энергии является ЮПСка, «дотягивающая» в итоге напряжение на батареях до Uз. Зарядный ток в этом случае делится между всеми батареями - в зависимости от потребности каждой в каждый момент времени заряда. Заряжаться все вместе будут, естественно, дольше, но это не вредит батареям.

С учетом выкладок выше думаю, что последовательное соединение аккумуляторов (в больших ЮПСках) даже более вредно - так как изменение параметров (или их изначальное различие) у одной батареи будет сказываться на режиме работы другой. Хотя с точки зрения преобразователя лучше, конечно, работать с более высоким напряжением, чем гонять ток в десятки Ампер по ключам / дорожкам платы / etc. Но речь сейчас именно о батареях.

В общем, дискасс.

PS: да, а к Linux'у это имеет то отношение, что от ЮПСки работает линуксовый сервер и через NUT ее контролирует :)

Я правильно понимаю, что ядерный memtest - это более удобная форма ранее использовавшегося badram-патча? Что первый, что второй служат одной цели - исключать битые ячейки памяти, однако последний требовал отдельного запуска memtest86+ и более не развивается (последний патч для 28-го ядра).

В системной библиотеке GNU C Library (glibc), являющейся основой большинства Linux-дистрибутивов, обнаружена критическая уязвимость, позволяющая любому локальному пользователю получить привилегии суперпользователя. Проблема вызвана игнорированием в Glibc требования спецификации ELF по запрещению использования текущего пути к исполняемому файлу ($ORIGIN) в процессе динамического связывания программ с идентификатором смены владельца или группы (suid/sgid). Проблема проявляется в конфигурациях, в которых пользователь имеет возможность создавать жесткие ссылки в файловой системе, допускающей наличие suid-файлов.

Уязвимость протестирована в Fedora 13 и RHEL 5 / CentOS 5, другие дистрибутивы судя по всему также подвержены проблеме. Исправления пока недоступны, статус выхода обновлений в различных Linux-дистрибутивах можно наблюдать на следующих страницах: Slackware, Gentoo, Mandriva, openSUSE, CentOS, Fedora, RHEL, Debian, Ubuntu.

Проблема была известна и ранее, но разработчики Glibc считали, что эксплуатировать ее невозможно. Используя режим аудита связывания программ (LD_AUDIT) в ld.so, вкупе с подменой $ORIGIN через создание жесткой ссылки и запуском suid-программы через файловый дескриптор, удалось разработать практический метод атаки.

http://www.opennet.ru/opennews/art.shtml?num=28338

Debian Squeeze, ejabberd 2.1.5, завязал его на MySQL по этому мануалу - https://support.process-one.net/doc/display/MESSENGER/Using+ejabberd+with+MyS... - однако в таком варианте не работают расширенные статусы. Помогает возврат с mod_pubsub_odbc на mod_pubsub.

Оно в принципе так не работает (зачем тогда соответствующие таблицы в базе?) или я что-то не сделал? Сходу ничего не гуглится, те варианты, которые находил (статьи по настройке такой связки) были c mod_pubsub.

Сабж.

Пруф:
http://clubs.ya.ru/jabber/replies.xml?item_no=9363
http://www.jabber.ru/node/1695

Дорогие друзья! После длительного отсутствия мы снова в сети!

На неопределенный срок открыта свободная регистрация, на неопределенный срок на трекере свободное скачивание без учета даунлоада, на неопределенный срок на трекере тройной учет аплоада!

Пользуйтесь на здоровье!

http://hdtracker.ru

Пару дней назад обновил ejabberd до 2.1.5 (из Debian Squeeze) на своем сервере, сегодня заметил, что чатлоги (из mod_muc_log) теперь с правами 640 вместо старых 644. В парамерах модуля ничего относящегося к правам на файлы нет / не нашел. Создал тестовую конференцию, права на вновь создаваемые подкаталоги тоже ставятся более «закрытые» - 750:

$ ls -al testtest@conference.linuxoid.in/2010/09/
total 8
drwxr-x--- 2 ejabberd ejabberd   72 2010-09-29 21:41 .
drwxr-x--- 3 ejabberd ejabberd   72 2010-09-29 21:41 ..
-rw-r----- 1 ejabberd ejabberd 7807 2010-09-29 21:41 29.html

Никто с подобным не сталкивался? Как фиксить?

Создаю RAID5-массив на свежекупленных дисках, озаботился вопросом выравнивания разделов. Сделал так, как было рассказано в различных мануалах (т.е., создал раздел на 2^n секторе), в итоге получилось такое:

fdisk -u -l /dev/sdb

Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048  1953525167   976761560   fd  Linux raid autodetect

Критично ли то, что cfdisk при такой разбивке ругается на «FATAL ERROR: Bad primary partition 0: Partition ends in the final partial cylinder» или можно не обращать внимания?

И да, почему при

mdadm -C -l5 -n3 /dev/md0 /dev/sdb1 /dev/sdc1 /dev/sdd1

1 - должен был стартовать со всеми дисками и начать перестраиваться

2 - даже если стартовал так, как стартовал - сразу начать использовать hot spare для ребилда.

----

Debian Squeeze,

root@mws64:~# mdadm --version
mdadm - v3.1.2 - 10th March 2010
root@mws64:~# uname -a
Linux mws64 2.6.35.4-mws64 #1 SMP PREEMPT Sat Aug 28 19:27:45 EEST 2010 x86_64 GNU/Linux

Некоторое время назад я создавал тему про беспричинные фризы rtorrent'a - http://www.linux.org.ru/forum/general/4877922

Вот уже где-то неделю наблюдаю нормальную работу без каких-либо фризов. Как и в прошлой теме, в конфигурации ничего не менялось (разве что пару недель назад разрешил в rtorrent'e только шифрованные соединения), машина работает уже долгое время и т.д. и т.п. Он просто сам по себе вдруг начал нормально работать.

rain@prox:~$ uptime
09:08:02 up 48 days, 13:16, 4 users, load average: 0.72, 1.05, 1.28

Что это было - хз.

Такие дела.

Вышли обновления для веток 2.6.27, 2.6.32, 2.6.35; соответственно, 2.6.27.54, 2.6.32.22 и 2.6.35.5

Никто не в курсе, с каких адресов оттуда ведется скан торрент-трекеров, чтобы забанить их в iptables? Когда-то добавил адрес в список трекеров, в последнее время нагрузка растет и полмиллиона пиров уже немного напрягают; хочу закрыться от сканера, чтобы рейтинг снизился и трекер больше не использовали всякие-разные боты.

Только что в RSS упало - http://www.nixp.ru/news/Определено-кодовое-имя-Debian-GNU-Linux-7-0-Wheezy.html

Небольшой диалог:

------------------
[17:11:06] <Vlas> смотри, тарю каталог tar cjf file.tar directory --remove-files
[17:11:17] <Vlas> при этом удаляются файлы в каталоге
[17:11:21] <Vlas> но сам каталог жив
[17:12:40] <Vlas> нужно что и сам каталог удалялся
[17:13:00] <Vlas> тару такое можно как-то сказать ?
[17:13:25] <rain> а просто снести каталог после выполнения задания сложно?
[17:13:37] <Vlas> да нет, не сложно
[17:13:54] <rain> просто тут еще такая вещь...
[17:14:04] <rain> rain@acnote:/tmp$ tar cf etc.tar etc --remove-files
tar: /usr/bin/Xorg: Функция unlink завершилась с ошибкой: Отказано в доступе
tar: /usr/share/icons/Chameleon-White-Small/cursor.theme: Функция unlink завершилась с ошибкой: Отказано в доступе
tar: /usr/share/icons/Chameleon-Pearl-Regular/cursor.theme: Функция unlink завершилась с ошибкой: Отказано в доступе
и так далее
[17:14:10] <rain> сносит он слегка стремно :)
[17:14:25] <Vlas> понятно :)
[17:14:37] <Vlas> ну у этого тара будет доступ всегда :)
[17:14:44] <rain> поэтому если у тебя где-то случайно будет ссылка на корень... Ну, ты понял
------------------

etc в моем случае - копия /etc от пользователя, соответственно, там вполне могут быть ссылки куда-либо еще.

Собственно, в чем вопрос: это бага tar'a, что он по ссылкам вылазит в остальную файловую систему и пытается ее снести? Пакует-то он нормально, оставляя ссылки ссылками, а не копируя контент.

$ tar --version
tar (GNU tar) 1.23

Debian Squeeze