Цель: Есть такой хомячковый ресурс ВКонтакте, так вот на нем море музыки выложенной самими пользователями данной социалки и прослушивая сия море медии можно отмечать понравившиеся мелодии тем самым коллекционировать у себя список "любимых" треков.
Но все хорошо когда есть GUI'ёвый браузер и доступ к ресурсу, а когда нет такого? К примеру браузера нет под рукой, или аудиосистема подключена дома к основному компу на котором Linux, а сам лежишь в соседней комнате с ноутом ... ?
Одним словом нужно было что то типа из под консоли (командной строки)!
Показаны сообщения с ярлыком linux. Показать все сообщения
Показаны сообщения с ярлыком linux. Показать все сообщения
25 апр. 2011 г.
10 февр. 2011 г.
вторая жизнь "железяки-router'a" ...
На заметку: Недавно в руки получил обычечный DIR-300, с жалобами о нестандартности сия... Глянув в глубину души железячки, осознал что роутер далеко не обычечный =) Жил в нём некий DD-WRT!
Идея весьма понравилась, даже тем, что позволяет расширить функционал невзрачных, бюджетных, домашних маршрутизаторов.
12 мар. 2010 г.
VirtualBox и тележечка приятностей ...
Цель: научить гостевые ОС работать с общими папками
Дано: Виньдовсъ ХыПы, VirtualBox 3.1.2, гостевая ОСь fedora 2.6.27.5-117.fc10.i686
Решение:
Вроде ничего страшного, бери и пользуйся, всё в пояснениях есть при создании общей папки типа используйте следующее:
и будет вам счастье ...
но не нам, естественно что чистая гостевая ось не знает ни о какой файловой системе vboxsf и с страшным визгом о чем нас заверяет следующим сообщением:
или на рашен если
что же, всё куда проще чем могло быть:
1) в настройках гостевой ОС добавляем оптический привод, если такого ранее не наблюдалось, это вам в "Детали", там "Носители" и только там соответственные кнопки имеются для данной цели.
2) после, запускаем гостевую ОС нашу, и в меню бокса гостевой ОС открываем пункт Устройства, где черным по серому писано: "Установить дополнения гостевой ОС ... (Host+D)"
3) в самой гостевой ОС, если сидюк не монтируется сам при запуске ОС, то пишем
соответственно /mount/cdrom должно быть уже, иначе перед монтированием
4) идем в новь смонтированную папку и запускаем там соответствующее нашей платформе бинарничек (в моем случае VBoxLinuxAdditions-x86.run):
ждем завершения ...
и вроде бы всё, всё должно как бы уже работать ... НО ... счастливчик), пробуем
на что получаю новое ругательство ...
самое интересное в логах системы ничего ругательного на тему нашу не нашлось ... чисто, а mount.vboxsf вербозную опцию, увы, не поддерживает ...
м'да ... и тут нас не поколебало сия несчастие ...
оказывается для общих папок не желательно использовать "расшаренные папки" («Совместного использования файлов и принтеров») на хозяин ОС. Другими словами если на хозяин ОС у меня есть папка "sharename" которая расшаренная и доступна по сети, то используя VBox и общие папки ссылаясь на данную "расшаренную папку "sharename"", вылетает та злосчастная надпись: "mounting failed with the error: Protocol error"
два пути
1) создать папку "sharename1" хоть в нутри "sharename", хоть в другом месте, самое главное не расшаривать её, или
2) снять расшаривание с папки "sharename"
вот собственно и всё, после чего
чем сия поведение обусловлено, не знаю.
За любые уточнение буду весьма признателен.
Дано: Виньдовсъ ХыПы, VirtualBox 3.1.2, гостевая ОСь fedora 2.6.27.5-117.fc10.i686
Решение:
Вроде ничего страшного, бери и пользуйся, всё в пояснениях есть при создании общей папки типа используйте следующее:
mount -t vboxsf [-o OPTIONS] sharename mountpoint
и будет вам счастье ...
но не нам, естественно что чистая гостевая ось не знает ни о какой файловой системе vboxsf и с страшным визгом о чем нас заверяет следующим сообщением:
unknown filesystem type 'vboxsf'
или на рашен если
неизвестный тип файловой системы 'vboxsf'
что же, всё куда проще чем могло быть:
1) в настройках гостевой ОС добавляем оптический привод, если такого ранее не наблюдалось, это вам в "Детали", там "Носители" и только там соответственные кнопки имеются для данной цели.
2) после, запускаем гостевую ОС нашу, и в меню бокса гостевой ОС открываем пункт Устройства, где черным по серому писано: "Установить дополнения гостевой ОС ... (Host+D)"
3) в самой гостевой ОС, если сидюк не монтируется сам при запуске ОС, то пишем
#sudo mount -o loop /dev/cdrom /mount/cdrom
соответственно /mount/cdrom должно быть уже, иначе перед монтированием
#sudo mkdir /mount/cdrom
4) идем в новь смонтированную папку и запускаем там соответствующее нашей платформе бинарничек (в моем случае VBoxLinuxAdditions-x86.run):
#cd /mount/cdrom && ls
#sudo ./VBoxLinuxAdditions-x86.run
ждем завершения ...
и вроде бы всё, всё должно как бы уже работать ... НО ... счастливчик), пробуем
#sudo mount -t vboxsf sharename mountpoint
на что получаю новое ругательство ...
"mounting failed with the error: Protocol error"
самое интересное в логах системы ничего ругательного на тему нашу не нашлось ... чисто, а mount.vboxsf вербозную опцию, увы, не поддерживает ...
м'да ... и тут нас не поколебало сия несчастие ...
оказывается для общих папок не желательно использовать "расшаренные папки" («Совместного использования файлов и принтеров») на хозяин ОС. Другими словами если на хозяин ОС у меня есть папка "sharename" которая расшаренная и доступна по сети, то используя VBox и общие папки ссылаясь на данную "расшаренную папку "sharename"", вылетает та злосчастная надпись: "mounting failed with the error: Protocol error"
два пути
1) создать папку "sharename1" хоть в нутри "sharename", хоть в другом месте, самое главное не расшаривать её, или
2) снять расшаривание с папки "sharename"
вот собственно и всё, после чего
#sudo mount -t vboxsf sharename1 mountpoint && ls mountpoint
file1 file2 file3 etc
чем сия поведение обусловлено, не знаю.
За любые уточнение буду весьма признателен.
2 февр. 2010 г.
Повесть о mcabber под Mandriva Linux
Цель: Отображать кириллицу в консольном клиенте jabber'a
Дано:
Linux 2.6.22.9-desktop-1mdv
ncurses-5.7-3.20090207
libncursesw5-5.7-3.20090207
mcabber-0.9.9 (из штатного репозитория)

Незадача:
страшные "крякозябры" после запуска клиeнта и коннекта к jabber.ru
пляски с конфигом клиента или установкой переменной среды в ru_RU etc ни к чему не привели.
Примечание:
Скрин ситуевины прикрепил, до самих истин не добрался.
Если кто знает, на будущее, поведайте, буду весьма признателен.
Дано:
Linux 2.6.22.9-desktop-1mdv
ncurses-5.7-3.20090207
libncursesw5-5.7-3.20090207
mcabber-0.9.9 (из штатного репозитория)
Незадача:
страшные "крякозябры" после запуска клиeнта и коннекта к jabber.ru
пляски с конфигом клиента или установкой переменной среды в ru_RU etc ни к чему не привели.
Решение:
А вот так мне и надо, привык из репозитория ставится!
Угуглившись толком решения не увидел, есть пару-тройку отголосков предполагающих решение, и ничего личного к Мандриве самой, но ситуация данная на ней только. Что подтверждает поиски по гуглу и чисто ради эксперимента установка того же клиента на Ubuntu из репозиториев, который с ходу та и заработал.
И так, качаем исходники клиента, собираем, ставим.
Штатно, и работает как надо апосля ;)
#wget http://mcabber.com/files/mcabber-0.9.10.tar.bz2
#tar xjf ./mcabber-0.9.10.tar.bz2 && cd ./mcabber-0.9.10
#./configure && make && make install
Примечание:
Скрин ситуевины прикрепил, до самих истин не добрался.
Если кто знает, на будущее, поведайте, буду весьма признателен.
23 сент. 2009 г.
Тормозилла системы ...
Цель: Ограничиваем прожорливость npviewer.bin'а
Дано: Mozilla Firefox 3.0.13, nspluginwrapper 1.3.0, npviewer.bin 1.3.0, Linux 2.6.29.6-desktop
Решение:
Не раз замечал утечку npviewer.bin'а (кушал много процессорного времени, вражина эдакая!), при проигрывании flash'ы в мозилле, дык бы отказался, но вот по рабочим вопросам не позволительно ...
на офф сайте nspluginwrapper, ничего вразумительного не нашлось ... увы.
Устранить по человечески, да вот руки не доходили, обходился чистым ps grep && kill ... но частота такой ситуации увеличивалась (теперь наверно каждый веб-фломастер считает долгом сунуть на свой сайт рекламку на флэше) и каждый раз тюкать так ... увы не наш метод.
Сперва нарисовал для себя что то подобное
как результат работы, никакой флэши, да вот забыл, что нужные мне ролики он так же глушить будет ... данное решение не устроило ...
Вспомнилась к счастью, а может и нет, утилитка cpulimit, не во всех дистрах есть но в репозиториях практически у всех, ставим, наслаждаемся (под рутом):
лимит сами выставляйте, по своим требованиям, в данном случае -l 10 (limit 10%).
для того что бы вообще про неё забыть раз навеки или хотя бы до той поры пока утечку не устранят (кстати наблюдалась она и на более ранних реализациях данного бина) занесем последнюю строчку в rc.local:
Примечание:
глянуть где npviewer.bin
глянуть где cpulimit
Дано: Mozilla Firefox 3.0.13, nspluginwrapper 1.3.0, npviewer.bin 1.3.0, Linux 2.6.29.6-desktop
Решение:
Не раз замечал утечку npviewer.bin'а (кушал много процессорного времени, вражина эдакая!), при проигрывании flash'ы в мозилле, дык бы отказался, но вот по рабочим вопросам не позволительно ...
на офф сайте nspluginwrapper, ничего вразумительного не нашлось ... увы.
Устранить по человечески, да вот руки не доходили, обходился чистым ps grep && kill ... но частота такой ситуации увеличивалась (теперь наверно каждый веб-фломастер считает долгом сунуть на свой сайт рекламку на флэше) и каждый раз тюкать так ... увы не наш метод.
Сперва нарисовал для себя что то подобное
for name in $(ps ux | awk '/npviewer.bin/ && !/awk/ {print $2}'); do kill "$name"; doneкак результат работы, никакой флэши, да вот забыл, что нужные мне ролики он так же глушить будет ... данное решение не устроило ...
Вспомнилась к счастью, а может и нет, утилитка cpulimit, не во всех дистрах есть но в репозиториях практически у всех, ставим, наслаждаемся (под рутом):
#urpmi cpulimit
#cpulimit -e /usr/lib/nspluginwrapper/i386/linux/npviewer.bin -l 10 &
лимит сами выставляйте, по своим требованиям, в данном случае -l 10 (limit 10%).
для того что бы вообще про неё забыть раз навеки или хотя бы до той поры пока утечку не устранят (кстати наблюдалась она и на более ранних реализациях данного бина) занесем последнюю строчку в rc.local:
#echo '/usr/bin/cpulimit -e /usr/lib/nspluginwrapper/i386/linux/npviewer.bin -l 10 &' >> /etc/rc.local
Примечание:
глянуть где npviewer.bin
#ps ux | awk '/npviewer.bin/ && !/awk/ {print $11}'глянуть где cpulimit
#whereis cpulimit
8 мая 2009 г.
SSH linux-клиента через Microsoft's ISA server
Цель: Пустить весь трафик "прозрачно" с Linux машины через ISA сервер
Решение:
Сразу скажу, полностью "прозрачно" пустить так и не удалось.
Интересовал трафик SSH клиента по большей части, поэтому когда завел kerberos c squid'ом (с режимом transparent) кроме прозрачного проксирования http(s) трафика более не удалось. SSH клиент по прежнему ломился напрямую ...
По ключевым словам ISA server SSH proxy наткнулся на ховтушку, популярно описывающая как пустить SSH трафик через ISA с использованием putty под никсы. Но увы, и тут меня ждало разочарование...
Ховтушка повествует нам о подключении с помощью putty и скрипта NTLMaps написанного на питоне, что тоже не на каждом серве стоит) на удаленную машину предварительно завесив демона SSHD на 443 порт (хотя тут вполне достаточно было перенаправления с 443 на 22) что весьма не удобно, ведь речь идет о управлении далеко не домашними машинами, да и 443 порт может уже прослушиваться на удаленке Apache'м ...
Смысл в том, что админа рабочей локальной сети в любом случае дернуть придется (хотя с этим проблем нет, но признавать свое поражение не хотелось ;) ), дабы разрешил своими правилами на ISA сервере SSL соединения помимо 443 порта, все мои попытки соединения как и на стандартный порт 22 так и на иные типа 8022 и т.д. через ISA потерпели неудачу комментированную ISA сервером о запрете транзитного SSL трафика отличного от порта 443-го.
Примечание: Иными словами постучавшись об стену два дня, решения задачи так и не найдено. Точнее оно есть, покинув рабочую локальную сеть =), только вот теперь осталось верно аргументировать данный факт перед руководством. =)
Решение:
Сразу скажу, полностью "прозрачно" пустить так и не удалось.
Интересовал трафик SSH клиента по большей части, поэтому когда завел kerberos c squid'ом (с режимом transparent) кроме прозрачного проксирования http(s) трафика более не удалось. SSH клиент по прежнему ломился напрямую ...
По ключевым словам ISA server SSH proxy наткнулся на ховтушку, популярно описывающая как пустить SSH трафик через ISA с использованием putty под никсы. Но увы, и тут меня ждало разочарование...
Ховтушка повествует нам о подключении с помощью putty и скрипта NTLMaps написанного на питоне, что тоже не на каждом серве стоит) на удаленную машину предварительно завесив демона SSHD на 443 порт (хотя тут вполне достаточно было перенаправления с 443 на 22) что весьма не удобно, ведь речь идет о управлении далеко не домашними машинами, да и 443 порт может уже прослушиваться на удаленке Apache'м ...
Смысл в том, что админа рабочей локальной сети в любом случае дернуть придется (хотя с этим проблем нет, но признавать свое поражение не хотелось ;) ), дабы разрешил своими правилами на ISA сервере SSL соединения помимо 443 порта, все мои попытки соединения как и на стандартный порт 22 так и на иные типа 8022 и т.д. через ISA потерпели неудачу комментированную ISA сервером о запрете транзитного SSL трафика отличного от порта 443-го.
Примечание: Иными словами постучавшись об стену два дня, решения задачи так и не найдено. Точнее оно есть, покинув рабочую локальную сеть =), только вот теперь осталось верно аргументировать данный факт перед руководством. =)
Подписаться на:
Сообщения (Atom)

