Re[2]: показать в папке - открывается менеджер архивов
> >"И добавить в файл ~/.local/share/applications/defaults.list ссылку на .desktop >файл любимого менеджера "папок": > > application/x-directory=/usr/share/applications/pcmanfm.desktop > application/x-desktop=/usr/share/applications/pcmanfm.desktop > x-directory/normal=/usr/share/applications/pcmanfm.desktop" Не помогло, Debian squeeze, gnome >
Re: Debian в роли свитча
Artem Chuprina -> debian-russian@lists.debian.org @ Thu, 06 Feb 2014 02:35:31 +0400: AC> Так и работает. Идея софтверного бриджа в том, что физические AC> интерфейсы становятся портами свитча. А интерфейс бриджа - интерфейсом AC> самого свитча. Как у обычных настраиваемых свитчей, у которых портов AC> много, а адрес один. И в какой порт к нему ни воткнись, он по этому AC> адресу доступен. И если у него этот адрес настроен на DHCP, то он AC> получает его от DHCP-сервера, видимого через любой порт. Впрочем, у меня это почти чисто теория. Нет, я даже на домашнем сервере (включен Xen, хотел завести винду, но обломался) его настроил, типа, по инструкции. Но там бридж в сторону локалки, и адрес статический. А вышеприведенное рассуждение - чисто на здравом смысле. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fvnxqj4v@wizzle.ran.pp.ru
Re: Debian в роли свитча
Andrey B. Kiselev -> debian-russian@lists.debian.org @ Thu, 6 Feb 2014 00:14:37 +0400: ABK> Моему провайдеру не пофигу :) Верней не так - провайдеру пофигу, а клиентам ABK> лишний геморрой. Либо свитч на входе и втыкай что угодно, в т.ч. ТВ, либо ABK> ставь роутер и настраивай там igmp proxy. Второй вариант неубедителен, ибо ABK> будет захлебывается WiFi, т.к. на него ТВ-шный трафик тоже сыпется. ABK> Поэтому и приходится прибегать к извращениям. Я, кстати, сильно подозреваю, что IGMP proxy можно настроить так, чтобы он кидал во внутреннюю сеть только на избранного клиента. Вот можно ли настроить конструкцию так, чтобы он кидал его не на все физические интерфейсы бриджа... Подозреваю, что тоже можно, средствами ebtables. Но настроить второй бридж, вероятно, тупо проще. ABK> Протестировал на виртуалке предыдущий вариант (аплинк и ТВ в бридж, адрес ABK> получает бридж). Вроде более-менее работает, хотя не понимаю как. Будет ABK> время проверю на боевом железе. Так и работает. Идея софтверного бриджа в том, что физические интерфейсы становятся портами свитча. А интерфейс бриджа - интерфейсом самого свитча. Как у обычных настраиваемых свитчей, у которых портов много, а адрес один. И в какой порт к нему ни воткнись, он по этому адресу доступен. И если у него этот адрес настроен на DHCP, то он получает его от DHCP-сервера, видимого через любой порт. ABK> 5 февраля 2014 г., 22:34 пользователь Artem Chuprina написал: >> Черноус Алексей -> debian-russian@lists.debian.org @ Wed, 5 Feb 2014 >> 19:40:56 +0200: >> >> ЧА> У меня немного другая ситуация, но думаю поможет: >> ЧА> В eth0 кабель от провайдера (подключение через pppoe), в eth1 кабель >> от >> ЧА> всей локальной сети, в которой имеется и телевизор. В настройках >> ЧА> телевизора прописал IP компа (192.168.0.1) как шлюз, а на компе >> ЧА> запускаю скрипт: >> ЧА> #!/bin/bash >> ЧА> NET_IFACE="ppp0" >> ЧА> TV_IP="192.168.0.81" >> ЧА> TV_MAC="78:AA:BB:B7:23:54" >> ЧА> iptables -t filter -F >> ЧА> iptables -t nat -F >> ЧА> iptables -t filter -A FORWARD -m mac --mac-source $TV_MAC -j ACCEPT >> ЧА> iptables -t nat -A POSTROUTING -s $TV_IP -o $NET_IFACE -j MASQUERADE >> ЧА> echo "1" > /proc/sys/net/ipv4/ip_forward >> >> ЧА> Работает это примерно так: комп фильтрует пакеты от TV_MAC телевизора >> и >> ЧА> передаёт их на интерфейс NET_IFACE провайдера, предварительно >> ЧА> замаскировав локальный IP телевизора. >> >> Кстати, да. Провайдеру должно быть пофигу, один адрес у роутера и >> телевизора, или разные. >> >> >> -- >> To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org >> with a subject of "unsubscribe". Trouble? Contact >> listmas...@lists.debian.org >> Archive: http://lists.debian.org/87sirxqugf@wizzle.ran.pp.ru >> >> -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k3d9qjbg@wizzle.ran.pp.ru
Re: Что тяжелее - внешний процесс или вызов библиотеки?
Evgeny M. Zubok -> debian-russian@lists.debian.org @ Thu, 06 Feb 2014 00:57:01 +0400: EMZ> Вообще, утилиты в *NIX надо бы писать изначально так, чтобы ими было EMZ> удобно пользоваться в скриптах: то есть не только human-readable вывод EMZ> делать, но также и удобный текстовый вывод для скриптов. Лучше даже EMZ> как-то однообразно и для всех утилит, чтобы можно было единым образом EMZ> получать какие-то параметры, единообразно получать информацию о EMZ> прогрессе (если таковая выдается). Но вот как-то не сложилось в нашем EMZ> мире. Культура у разработчиков разная. Если мне придется в будущем EMZ> делать какие-то утилиты, то я изначально буду проектировать так, чтобы EMZ> можно было удобно скриптовать. Вот как-то не удается народу придумать более-менее универсальный протокол машинночитаемого обмена данными. В основном не удается задать структуру. EMZ> Если по теме, то от утилиты зависит. Смотря какая утилита, смотря какая EMZ> библиотека. Одни ломают каждый раз вывод, другие годами ничего трогают, EMZ> а некоторые даже принципиально не меняют. Библиотека тоже смотря какая. Все-таки утилита, выдающая человекомчитаемый формат, не только не обязана, но ей и не следует упорствовать в неменянии формата. Мне попадалось одна-две утилиты (rsync вот сходу вспоминается), у которых есть _отдельный_ машинночитаемый формат. И то он у них обычно далек от универсального, в смысле, страдает хреновой расширяемостью. Трудно добавить данные. Ну, для rsync это не так страшно, у него все же задача ограничена, там и нечего добавлять в отчет. Прогресс, кстати, отдельный таракан. Понимание того, какую часть работы ты уже сделал - отдельная задача, в ряде случаев еще и теоретически неразрешимая. А в ряде других - разрешимая, но за слишком большую дополнительную цену. Вон, у того же rsync сколько ручек для оптимизации обработки набора файлов для синхронизации. Две трети из них приводят к не особой осмысленности информации о прогрессе. Ну, знаешь ты, что тебе еще треть файлов копировать. А по времени? Правильно, пока он все файлы не синхронизирует, он этого не знает. Теория вероятности не помогает, распределение изменений, как правило, неравномерно. А когда синхронизировал - ну, 100%. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ob2lqjqo@wizzle.ran.pp.ru
Re: Что тяжелее - внешний процесс или вызов библиотеки?
Oleksandr Gavenko writes: > Формат вывода большинства утилит не стандартизирован, отсутствует > документация и гарантии что новые версии не изменят формат вывода, > тогда как для библиотечных вызовов зачастую есть документация и вызовы > предварительно помечаются как устаревшие, обратно-несовместимые > библиотеки изменяют пространство имен. > > С этой точки зрения библиотеки предпочтительней. Дельного ничего не посоветую, а просто повздыхаю. Это беда, на самом деле. Зачастую выпарсивание нужных данных выглядит как нереально страшный костыль. Правильно вот выше заметили. Причем костыль, который завтра может запросто поменяться и вообще сбить с толку прежний код. Вообще, утилиты в *NIX надо бы писать изначально так, чтобы ими было удобно пользоваться в скриптах: то есть не только human-readable вывод делать, но также и удобный текстовый вывод для скриптов. Лучше даже как-то однообразно и для всех утилит, чтобы можно было единым образом получать какие-то параметры, единообразно получать информацию о прогрессе (если таковая выдается). Но вот как-то не сложилось в нашем мире. Культура у разработчиков разная. Если мне придется в будущем делать какие-то утилиты, то я изначально буду проектировать так, чтобы можно было удобно скриптовать. Если по теме, то от утилиты зависит. Смотря какая утилита, смотря какая библиотека. Одни ломают каждый раз вывод, другие годами ничего трогают, а некоторые даже принципиально не меняют. Библиотека тоже смотря какая. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txcdmg6a@tochka.ru
Re: Debian в роли свитча
Моему провайдеру не пофигу :) Верней не так - провайдеру пофигу, а клиентам лишний геморрой. Либо свитч на входе и втыкай что угодно, в т.ч. ТВ, либо ставь роутер и настраивай там igmp proxy. Второй вариант неубедителен, ибо будет захлебывается WiFi, т.к. на него ТВ-шный трафик тоже сыпется. Поэтому и приходится прибегать к извращениям. Протестировал на виртуалке предыдущий вариант (аплинк и ТВ в бридж, адрес получает бридж). Вроде более-менее работает, хотя не понимаю как. Будет время проверю на боевом железе. 5 февраля 2014 г., 22:34 пользователь Artem Chuprina написал: > Черноус Алексей -> debian-russian@lists.debian.org @ Wed, 5 Feb 2014 > 19:40:56 +0200: > > ЧА> У меня немного другая ситуация, но думаю поможет: > ЧА> В eth0 кабель от провайдера (подключение через pppoe), в eth1 кабель > от > ЧА> всей локальной сети, в которой имеется и телевизор. В настройках > ЧА> телевизора прописал IP компа (192.168.0.1) как шлюз, а на компе > ЧА> запускаю скрипт: > ЧА> #!/bin/bash > ЧА> NET_IFACE="ppp0" > ЧА> TV_IP="192.168.0.81" > ЧА> TV_MAC="78:AA:BB:B7:23:54" > ЧА> iptables -t filter -F > ЧА> iptables -t nat -F > ЧА> iptables -t filter -A FORWARD -m mac --mac-source $TV_MAC -j ACCEPT > ЧА> iptables -t nat -A POSTROUTING -s $TV_IP -o $NET_IFACE -j MASQUERADE > ЧА> echo "1" > /proc/sys/net/ipv4/ip_forward > > ЧА> Работает это примерно так: комп фильтрует пакеты от TV_MAC телевизора > и > ЧА> передаёт их на интерфейс NET_IFACE провайдера, предварительно > ЧА> замаскировав локальный IP телевизора. > > Кстати, да. Провайдеру должно быть пофигу, один адрес у роутера и > телевизора, или разные. > > > -- > To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: http://lists.debian.org/87sirxqugf@wizzle.ran.pp.ru > >
Re: Debian в роли свитча
Черноус Алексей -> debian-russian@lists.debian.org @ Wed, 5 Feb 2014 19:40:56 +0200: ЧА> У меня немного другая ситуация, но думаю поможет: ЧА> В eth0 кабель от провайдера (подключение через pppoe), в eth1 кабель от ЧА> всей локальной сети, в которой имеется и телевизор. В настройках ЧА> телевизора прописал IP компа (192.168.0.1) как шлюз, а на компе ЧА> запускаю скрипт: ЧА> #!/bin/bash ЧА> NET_IFACE="ppp0" ЧА> TV_IP="192.168.0.81" ЧА> TV_MAC="78:AA:BB:B7:23:54" ЧА> iptables -t filter -F ЧА> iptables -t nat -F ЧА> iptables -t filter -A FORWARD -m mac --mac-source $TV_MAC -j ACCEPT ЧА> iptables -t nat -A POSTROUTING -s $TV_IP -o $NET_IFACE -j MASQUERADE ЧА> echo "1" > /proc/sys/net/ipv4/ip_forward ЧА> Работает это примерно так: комп фильтрует пакеты от TV_MAC телевизора и ЧА> передаёт их на интерфейс NET_IFACE провайдера, предварительно ЧА> замаскировав локальный IP телевизора. Кстати, да. Провайдеру должно быть пофигу, один адрес у роутера и телевизора, или разные. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sirxqugf@wizzle.ran.pp.ru
Re: Debian в роли свитча
У меня немного другая ситуация, но думаю поможет: В eth0 кабель от провайдера (подключение через pppoe), в eth1 кабель от всей локальной сети, в которой имеется и телевизор. В настройках телевизора прописал IP компа (192.168.0.1) как шлюз, а на компе запускаю скрипт: #!/bin/bash NET_IFACE="ppp0" TV_IP="192.168.0.81" TV_MAC="78:AA:BB:B7:23:54" iptables -t filter -F iptables -t nat -F iptables -t filter -A FORWARD -m mac --mac-source $TV_MAC -j ACCEPT iptables -t nat -A POSTROUTING -s $TV_IP -o $NET_IFACE -j MASQUERADE echo "1" > /proc/sys/net/ipv4/ip_forward Работает это примерно так: комп фильтрует пакеты от TV_MAC телевизора и передаёт их на интерфейс NET_IFACE провайдера, предварительно замаскировав локальный IP телевизора. -- Алексей -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140205194056.3e573efc@mentor
Re: Debian в роли свитча
Andrey B. Kiselev -> debian-russian@lists.debian.org @ Wed, 5 Feb 2014 14:17:19 +0400: ABK> Приветствую. ABK> Может кто извращался аналогичным образом :) ABK> Имеется машинка на wheezy, которая в данный момент выполняет роль ABK> wifi-роутера. В eth0 подключен свитч, к которому в свою очередь приходит ABK> кабель от провайдера. eth1 и wlan0 объединены в бридж, к которому ABK> подключаются десктоп и прочие девайсы. ABK> Имеется в наличии также телевизионная приставка, которая должна получать IP ABK> строго от провайдера (сейчас воткнута в свитч, параллельно "роутеру"). По ABK> некоторым причинам возникла необходимость избавиться от свитча и подключить ABK> приставку через имеющийся "роутер", на котором остался свободен еще 1 ABK> интерфейс, он же eth2. ABK> Перерыл кучу доков, но адекватного решения не нашлось. ABK> Объединение eth2 в имеющийся бридж нецелесообразен, т.к. приставка получит ABK> адрес из домашней сетки, а не от провайдера. ABK> Если объединять eth0 и eth2 во второй бридж, которому назначить отдельный ABK> адрес - прихожу к тому, что ни приставка, ни "роутер" не получают айпишники. А почему, собственно? По идее, именно так оно и должно работать. Ну, роутер при этом должен получать адрес на br1, а не на eth0, т.е. не надо назначать ему отдельный адрес, надо просто не назначать адрес eth0 и eth2. Нет, сам не пробовал :) У меня дома ситуация обратная (два провайдера через свитч в один физический интерфейс роутера), поэтому у меня не бридж, а наоборот, VLAN. ABK> Можно ли как-то построить мост, при котором на обоих сетевых... Нет, не ABK> так... Мост, при котором и "роутер" и приставка будут получать каждый свои ABK> адреса и при этом можно будет: ABK> а) маршрутизировать трафик между провайдером и "роутером" (следовательно и ABK> всеми устройствами), ABK> б) коммутировать трафик от провайдера отдельно на приставку? ABK> Натыкался на vde (Virtual Distributed Ethernet), но как я понял, это ABK> подходит больше для виртулизации. Или нет? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877g99st0h@wizzle.ran.pp.ru
Debian в роли свитча
Приветствую. Может кто извращался аналогичным образом :) Имеется машинка на wheezy, которая в данный момент выполняет роль wifi-роутера. В eth0 подключен свитч, к которому в свою очередь приходит кабель от провайдера. eth1 и wlan0 объединены в бридж, к которому подключаются десктоп и прочие девайсы. Имеется в наличии также телевизионная приставка, которая должна получать IP строго от провайдера (сейчас воткнута в свитч, параллельно "роутеру"). По некоторым причинам возникла необходимость избавиться от свитча и подключить приставку через имеющийся "роутер", на котором остался свободен еще 1 интерфейс, он же eth2. Перерыл кучу доков, но адекватного решения не нашлось. Объединение eth2 в имеющийся бридж нецелесообразен, т.к. приставка получит адрес из домашней сетки, а не от провайдера. Если объединять eth0 и eth2 во второй бридж, которому назначить отдельный адрес - прихожу к тому, что ни приставка, ни "роутер" не получают айпишники. Можно ли как-то построить мост, при котором на обоих сетевых... Нет, не так... Мост, при котором и "роутер" и приставка будут получать каждый свои адреса и при этом можно будет: а) маршрутизировать трафик между провайдером и "роутером" (следовательно и всеми устройствами), б) коммутировать трафик от провайдера отдельно на приставку? Натыкался на vde (Virtual Distributed Ethernet), но как я понял, это подходит больше для виртулизации. Или нет?
Re: proga
5 февраля 2014 г., 13:14 пользователь Martin Danielyan < mr.danielya...@yahoo.com> написал: > нужна хорошая программ для анализа логов и трафика кто сколько куда > захадил, > Calamaris, ElasticSearch, NewRelic, perl, python
Re: proga
lightsquid, например 5 февраля 2014 г., 13:14 пользователь Martin Danielyan < mr.danielya...@yahoo.com> написал: > нужна хорошая программ для анализа логов и трафика кто сколько куда > захадил, > -- Boris
proga
нужна хорошая программ для анализа логов и трафика кто сколько куда захадил,
Re: белые списки в dhcp
2014-02-05 Hleb Valoshka <375...@gmail.com>:
> Добрый день!
>
> Подскажите, есть ли способ создания белых списков в isc dhcpd.
>
> Нужно следующее: есть N mac-адресов, каждому из них ставится в
> соответствие конкретный ip-адрес. Это делается просто и вопросов не
> вызывает.
>
> Но кроме них есть ещё M mac-адресов, получающих ip-адреса из общего
> пула, и кроме них никто более не должен иметь возможности получить
> адрес из пула.
>
> В документации на dhcpd говорится о классах <<известных>> и
> <<неизвестных>> клиентов, т.е., теоретически, <<известные>> клиенты это и
> есть нужный мне белый список, но только я не понял как произвольный
> адрес сделать <<известным>>.
>
обьявить их в конфигурации как
host client1 { hardware ethernet aa:bb:cc:dd:ee:ff ; }
белые списки в dhcp
Добрый день! Подскажите, есть ли способ создания белых списков в isc dhcpd. Нужно следующее: есть N mac-адресов, каждому из них ставится в соответствие конкретный ip-адрес. Это делается просто и вопросов не вызывает. Но кроме них есть ещё M mac-адресов, получающих ip-адреса из общего пула, и кроме них никто более не должен иметь возможности получить адрес из пула. В документации на dhcpd говорится о классах «известных» и «неизвестных» клиентов, т.е., теоретически, «известные» клиенты это и есть нужный мне белый список, но только я не понял как произвольный адрес сделать «известным».
