#!/bin/sh
< ...
+ развернуть текст сохранённая копия
#!/bin/sh
for file in `find /full/path/to/folder -print`
do
mv $file `echo $file | tr [:upper:] [:lower:]` 2>/dev/null
done
Тэги: freebsd, linux, openbsd
BSD news in Russian
2011-07-04 09:03:56
Если гора не идет к Магомету, то Магомет идет к горе.
(с) кто то, давно
Так как положение с ...
+ развернуть текст сохранённая копия
Если гора не идет к Магомету, то Магомет идет к горе.
(с) кто то, давно
Так как положение с новостями на русском языке, о BSD подобных ОС, если не ухудшается, то уж точно не улучшалось.
Поэтому было принято волевое решение и организован ресурс http://bsdnir.blogspot.com/, а так же сопутствующие сервисы. Назван не замысловато BSD news in Russian
(BSD новости по-русски), из чего вытекает основное направление деятельности, это предоставление новостей из мира BSD.
В качестве примеров для подражания были выбраны англоязычные ресурсы DragonFly BSD Digest и FreeBSD News, вот что то похожее и постараюсь создать.
Как и положено современному, особенно новостному ресурсу заведены, твиттер @bsdnir, причём он не является автогенерируемым, так же заведена страничка в facebook, там как раз статьи просто репостятся в заметки, ну и конечно же RSS лента.
Так что если кому то такая идея по душе, то не стесняйтесь присоединяться, так же буду рад любым замечаниям и предложениям :)
Этот блог не...
[content]
Тэги: bsd, freebsd, netbsd, openbsd, runix
Ненормальное программирование / Кто разводит рыбок? Или решение загадки Эйнштейна регулярным языком
2011-06-10 16:16:46
Многие сталкивались с головоломкой про пять разноцветных домов, в каждом из которых живет человек со ...
+ развернуть текст сохранённая копия
Многие сталкивались с головоломкой про пять разноцветных домов, в каждом из которых живет человек со своими любимыми животным, напитком и сигаретами. Эта загадка приписывается Эйнштейну, хотя прямых подтверждений этому нет. Полный текст этой головоломки есть на википедии.
Ее можно решить на бумаге или в уме, последовательно исключая неподходящие варианты. Однако, ее также можно решить более технично. Один из способов — написать программку на прологе. Но здесь я хочу ее решить используя более простые механизмы — регулярные выражения. А именно, перевести условия загадки на язык регекспов и свести задачу к поиску подходящей строки во всем допустимом наборе строк. Кстати, этот набор строк показан на рисунке.
Интересно? Прошу под кат.
Тэги: bash, expression, finite, logic, machine, openfst, regular, state
Multicast forward/routing Linux, OpenBSD (iptv).
2010-02-10 01:42:00
/*
в эпоху модемов с поддержкой V.22 (1,200 бит/с) даже думать о потоковом контенте было ...
+ развернуть текст сохранённая копия
/*
в эпоху модемов с поддержкой V.22 (1,200 бит/с) даже думать о потоковом контенте было страшно. времена меняются и в медвежьи берлоги вламываются результаты "электрификации всей стганы" с более-менее приемлимыми тарифными планами. при этом вполне оправдано появление устройств из категории "домашние роутеры", принимающих канал доступа в internet/локалку от провайдера и раздающих ресурсы грубо говоря "на всю квартиру". зачастую эту функцию берут на себя старенькие компы уровня Pentium-Pentium III под управлением Linux/OpenBSD. при этом зачастую Провайдер даёт выход в сеть internet при помощи vpn/dsl туннеля/подключения, а мультикаст (как например услуга iptv - потокового вещания видео) "крутится" в сегменте "локальной" сети. ниже постараюсь описать принципы настройки роутера для работы в данных условиях. материал не претендует на исчерпывающее изложение и какую-либо оригинальность. здесь не будет готовых рецептов - только общие рекомендации. если Вам понравилось или есть чем дополнить - милости прошу оставить комментарий.
***********************************************
намеренно оставил за рамками роутеры на FreeBSD, так как imho (хотел бы ошибаться, но практика, Господа...) эта система не содержит механизмов, позволяющих нормально решать вопросы динамического роутинга/форварда мультикаста одновременно с NAT-ом, о чём честно предупреждает handbook:
31.2.8 Multicast Routing
FreeBSD supports both multicast applications and multicast routing natively. Multicast applications do not require any special configuration of FreeBSD; applications will generally run out of the box. Multicast routing requires that support be compiled into the kernel:
options MROUTING
In addition, the multicast routing daemon, mrouted(8) must be configured to set up tunnels and DVMRP via /etc/mrouted.conf. More details on multicast configuration may be found in the manual page for mrouted(8).
Note: As of FreeBSD 7.0 the mrouted(8) multicast routing daemon has been removed from the base system. It implements the DVMRP multicast routing protocol, which has largely been replaced by pim(4) in many multicast installations. The related map-mbone(8) and mrinfo(8) utilities have also been removed. These programs are now available in the FreeBSD Ports Collection as net/mrouted.
также стоит помнить, что сам по себе демон "mrouted" морально устарел (Ben, it's dead! RIP...) и не рекомендован к использованию при наличии альтернатив.
***********************************************
OpenBSD
тут всё очень просто и понятно. сам механизм прекрасно документирован:
OpenBSD Multicasting
"dvmrpd" работает практически без нареканий и не вызывает трудностей при конфигурировании. также доступен и "старый" mrouted, если вдруг по каким-то причинам Вас не устроит dvmrpd. что-то добавить к замечательно изложенному материалу желания не возникает.
Linux
именно тот случай, когда обилие "оболочек"/(сиречь дистрибутивов) плодит анархию. начну с кратенького обзора специальных девайсов, разработанных в качестве роутеров для домашней сети.
вне зависимости от "железа" основную роль тут играют "прошивки". они могут быть закрытыми ("фирменными", что предустановлены на заводе-изготовителе) или открытыми (как dd-wrt, прошивки Олега для ASUS-ов и т.п.). с задачей форварда/роутинга мультикаста "из коробки" на отлично справляются лишь прошивки от Олега (вне зависимости от наличия vpn соединения). по крайней мере до сего дня dd-wrt содержали баг в ядре и в исходниках igmpproxy, препятствующий нормальному функционированию. подробности.
рассмотрим пример конфигурации роутера:
eth0 - интерфейс к локальной сети Провайдера (пусть будет сеть 10.0.0.0/8), обозначим как $IF_IN
ppp0 - vpn туннель с выходом в internet, обозначим как $IF_VPN
eth1 - интерфейс к "домашней" сети (адреса в пределах 192.168.1.0/24), обозначим как $IF_OUT
для "домашних роутеров" схема конфига осложняется тем, что в качестве eth1 (интерфейса к "домашней" подсети) выступает (как правило) бридж (br0), объединяющий Ethernet и Wireless интерфейсы (ессно при наличии этого самого wifi).
теперь немного чтива для любознательных:
общее описание мультикаста (English Wiki)
1. Multicast over TCP/IP HOWTO - старый, но добрый хау-ту.
2. Multicast Routing Code in the Linux Kernel - тоже не Откровение, но даёт понятие о (как минимум) двух стоящих внимания "хомячка" переменных:
/proc/net/ip_mr_vif - список интерфейсов, вовлечённых в обмен мультикаст пакетами
/proc/net/ip_mr_cache - текущий статус MFC (Multicast Forwarding Cache - кэш мультикаст пакетов)
3. Configuring Linux For Network Multicast - начальные сведения о конфигурации Linux ядра для роутинга мультикаста.
собсно с конфигурирования ядра и начнём. в обязательном порядке нам нужны следующие опции:
CONFIG_IP_ADVANCED_ROUTER=y (или же CONFIG_IP_ROUTER=y)
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
CONFIG_IP_MULTICAST=y
CONFIG_NET_IPIP=y
кроме того может возникнуть необходимость проконтролировать (cat имя_файла) и/или изменить (echo $ЗНАЧЕНИЕ > имя_файла) некоторые дополнительные параметры:
разрешаем форвард ipv4 пакетов:
$ cat /proc/sys/net/ipv4/conf/default/forwarding
1
разрешаем форвард мультикаста:
$ cat /proc/sys/net/ipv4/conf/[ $IF_IN | $IF_OUT ]/mc_forwarding
1
отключаем reverse path filtering:
$ cat /proc/sys/net/ipv4/conf/$IF_IN/rp_filter
0
для ядер 2.6.* может потребоваться принудительное указание "типа"/версии igmp пакетов (варианты значений - 0, 1 или 2, описание есть в исходниках ядра - /usr/src/linux/net/ipv4/igmp.c):
$ cat /proc/sys/net/ipv4/conf/[ $IF_IN | $IF_OUT ]/force_igmp_version
{0,1,2}
с ядром более-менее разобрались, остался вопрос к прикладному софту. потребуется:
iptables
igmpproxy
пакеты "net-tools" (route, traceroute) и "iproute2" (ip) для управления маршрутами/(роутинг)
tcpdump/wireshark для мониторинга
в роли igmpproxy может выступить pimd или проприетарный gated (эт если из пушки да по воробьям засадить...). есть ещё smcroute, но оно умеет только "статику" (не наш метод). ещё на просторах сети где-то бродят сборки "родного" древнего многострадального mrouted-а с патчами для Linux. не будем ворошить труп. RIP.
для начала на роутере очищаем все цепочки iptables (flush) и рисуем что-то типа:
-A INPUT -d 224.0.0.0/240.0.0.0 -p 2 -j ACCEPT # некоторые опускают ключ -d 224.0.0.0/240.0.0.0 и разрешают весь входящий igmp трафик
-A INPUT -d 224.0.0.0/240.0.0.0 -p udp -m udp ! --dport 1900 -j ACCEPT
-A FORWARD -d 224.0.0.0/240.0.0.0 -p udp -j ACCEPT
также можно включить некоторую страховку от сволочной и шкурной натуры Провайдера, принудительно увеличив TTL мультикаст-потока на одну единичку при прохождении нашего роутера (а то особо умные принудительно на мультикаст ставят TTL == 1, чтобы потешить ЧСВ, не иначе):
-t mangle -A PREROUTING -d 224.0.0.0/240.0.0.0 -p udp -j TTL --ttl-inc 1
после чего делаем тупой конфигурационный файл (читаем man!) для igmpproxy (вместо значений переменных $IF_IN/$IF_OUT подставить имена соответствующих интерфейсов ессно):
$ cat /etc/igmpproxy.conf
# good things to begin with :)
quickleave
phyint $IF_IN upstream
altnet 0.0.0.0/0
phyint $IF_OUT downstream
и запускаем демона (от рута):
# igmpproxy -c /etc/igmpproxy.conf
для того, чтобы тело взлетело осталось лишь правильно настроить роутинг/(маршрутизацию). здесь надо помнить, что источники выдачи сигнала могут присутствовать помимо указанных в плейлисте того же iptv. т.е. кроме собсно мультикаста (net 224.0.0.0/240.0.0.0 ) источник может иметь "левые" ip-ы типа 88.210.40.0/24, 77.94.170.0/24 и т.п.. это легко отслеживается tcpdump-ом/wireshark-ом если непосредственно на роутере стартануть VLC или MPlayer, собранный с поддержкой live555 и получить "картинку" видео. роутинг к этим "левым" адресам должен идти через $IF_IN, не затрагивая $IF_VPN! объясняться подобный "казус" может довольно просто. Провайдер зачастую делает пиринг с теми, кто держит нехилые "фермы", раздающие сам трафик, что и приводит к появлению в локальной сети (Провайдера) подобных "левых" адресов. или же "фермам" присваивают адреса "от фонаря". другими словами адрес, что прописан в плейлисте - это адрес для JOIN/LEAVE ("подписки" и "выписки" из мультикаст-группы), а сам источник udp потока может приползти откуда угодно.
напоследок могу лишь посоветовать посматривать на статистику $IF_IN при пользовании igmpproxy. известно, что [далеко] не всегда "отписка" проходит корректно и это вполне может забить канал рано или поздно (при активной смене каналов вы быстро заметите если что-то пойдёт не так...).
удачи.
*/
Тэги: multicast, openbsd
не было печали...
2009-11-12 18:32:00
/*
- Вовочка, выйди из класса и зайди, как это делает твой папа!
- ... ща.
пинком ...
+ развернуть текст сохранённая копия
/*
- Вовочка, выйди из класса и зайди, как это делает твой папа!
- ... ща.
пинком выносит дверь с коробкой, рвёт пуговицы на рубашке и орёт в охуевший и притихший класс:
- Шо, с-суки, не ждали?!
история не нова. в очередной раз "тихо и незаметно" на весь OBS спустили новые проверочные пресеты из Factory. "... как это мило...". вроде бы радоваться надо, но... смотрим:
кривые зависимости в пакете
проблемы с автоконфигурацией устройств (заметим мимоходом, что alsaconf теперь "магёт" только ISA карточки и легко ломает нормальную рабочую настройку)
Top 100 - наши, мля, чемпионы...
на этом весёленьком, в цветочек, фоне новые проверки иначе как издевательскими не назовёшь. о начале этой вечеринки можно пофтыкать в одной из моих старых заметок. новый "хит сезона":
+ /usr/lib/rpm/suse_update_desktop_file.sh -r elementary_test Utility Accessibility
ERROR: //tmp/elementary-svn_20091112_r43627-build/usr/share/applications/elementary_test.desktop is not an UTF-8 file
+ exit 1
error: Bad exit status from /var/tmp/rpm-tmp.26363 (%install)
5 баллов. т.е.:
1) мы имеем АБСОЛЮТНО КОШЕРНЫЙ "elementary_test.desktop" файл
2) скармливаем его макросу "%suse_update_desktop_file ", чтобы эта тварь добавила строку "X-SuSE-translate=true" (исключительно специфика SuSE)
3) мы выучили все freedesktop-овы спеки на desktop файло для меню и всё делаем без косяков и по фэн-шую!
4) мы всё равно идём нахуй, ибо файл не UTF-8! (патамучта, бля, все символы "внутри" этого файла в пределах ASCII таблицы и ессно, что он и определяется как ASCII text! yeah baby, yeah!)
если кто-то решит ещё и "*.spec" файлы на UTF проверять - буду старательно рисовать матерные камменты. понятно, что по сути это мелочи, что было/есть благое намерение как-то поправить дела с локализацией и т.п. и т.д.. но на фоне существующих багов в ПО подобные "тонкости и политесы" явно не к месту (да и не ко времени).
возврат в Linux восле OpenBSD проходит тяжело. куда ни глянь - всюду бардак и нихера толком не работает как положено. примеры:
1) в OpenBSD-current моя wi-fi карточка (RT2500 802.11g - RaLink) - на wpa2 выдала "честные" 802.11g и держала канал как трактор накатанную колею - на полную. Linux - сперва прыгаешь с патчами, чтобы monitor mode нормально заработал (aircrack2), потом...
2) звук: в OpenBSD-current всё из коробки согласно списку поддерживаемого оборудования. Linux - ... (отсоси, потом проси...)
3) экспансия xml-конфигов в Linux без удобных средств для их редактирования (достаточно один раз поработать в Mac OS X чтобы понять, как это "для людей" делать надо)
4) Linux: бардак с hal/devkit/polkit/etc... - песнь. есть спеки - но хер поймёшь, что из этих спеков ноне работает. пример: требуется при помощи hal монтировать все "ufs" партиции с опцией "ufstype=44bsd". раньше было просто. добавляем в policy:
<merge key="storage.policy.default.mount_option.ufstype=44bsd" type="bool">true</merge>
<append key="volume.policy.mount_option.ufstype=44bsd" type="bool">true</append>
и мы в шоколаде. все строго по спекам. но нет, именно эти опции надо похерить и отдать на откуп DE (Desktop Environment), а то, что многие предпочитают не использовать DE и обходиться простыми WM-ами (Window Manager) - никого не парит.
и т.д. и т.п.. в результате получается, что c удовольствием рисуешь вот такие странички wiki, и смотришь на Linux чуток... по-другому. enterprise-то конечно из OpenBSD никакой, но...
скоро в моих репо будет всем обновление Enlightenment-DR17-svn (очень удачный и стабильный снэпшот получился) - пользуйте.
на этой мажорной ноте позвольте поздравить всех с релизом openSuSE-11.2 и откланяться.
удачи.
*/
Тэги: obs, openbsd, suse
