белые списки в dhcp
Добрый день! Подскажите, есть ли способ создания белых списков в isc dhcpd. Нужно следующее: есть N mac-адресов, каждому из них ставится в соответствие конкретный ip-адрес. Это делается просто и вопросов не вызывает. Но кроме них есть ещё M mac-адресов, получающих ip-адреса из общего пула, и кроме них никто более не должен иметь возможности получить адрес из пула. В документации на dhcpd говорится о классах «известных» и «неизвестных» клиентов, т.е., теоретически, «известные» клиенты это и есть нужный мне белый список, но только я не понял как произвольный адрес сделать «известным».
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 ; }
proga
нужна хорошая программ для анализа логов и трафика кто сколько куда захадил,
Re: proga
lightsquid, например 5 февраля 2014 г., 13:14 пользователь Martin Danielyan mr.danielya...@yahoo.com написал: нужна хорошая программ для анализа логов и трафика кто сколько куда захадил, -- Boris
Re: proga
5 февраля 2014 г., 13:14 пользователь Martin Danielyan mr.danielya...@yahoo.com написал: нужна хорошая программ для анализа логов и трафика кто сколько куда захадил, Calamaris, ElasticSearch, NewRelic, perl, python
Debian в роли свитча
Приветствую. Может кто извращался аналогичным образом :) Имеется машинка на wheezy, которая в данный момент выполняет роль wifi-роутера. В eth0 подключен свитч, к которому в свою очередь приходит кабель от провайдера. eth1 и wlan0 объединены в бридж, к которому подключаются десктоп и прочие девайсы. Имеется в наличии также телевизионная приставка, которая должна получать IP строго от провайдера (сейчас воткнута в свитч, параллельно роутеру). По некоторым причинам возникла необходимость избавиться от свитча и подключить приставку через имеющийся роутер, на котором остался свободен еще 1 интерфейс, он же eth2. Перерыл кучу доков, но адекватного решения не нашлось. Объединение eth2 в имеющийся бридж нецелесообразен, т.к. приставка получит адрес из домашней сетки, а не от провайдера. Если объединять eth0 и eth2 во второй бридж, которому назначить отдельный адрес - прихожу к тому, что ни приставка, ни роутер не получают айпишники. Можно ли как-то построить мост, при котором на обоих сетевых... Нет, не так... Мост, при котором и роутер и приставка будут получать каждый свои адреса и при этом можно будет: а) маршрутизировать трафик между провайдером и роутером (следовательно и всеми устройствами), б) коммутировать трафик от провайдера отдельно на приставку? Натыкался на vde (Virtual Distributed Ethernet), но как я понял, это подходит больше для виртулизации. Или нет?
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
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 в роли свитча
Черноус Алексей - 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 в роли свитча
Моему провайдеру не пофигу :) Верней не так - провайдеру пофигу, а клиентам лишний геморрой. Либо свитч на входе и втыкай что угодно, в т.ч. ТВ, либо ставь роутер и настраивай там igmp proxy. Второй вариант неубедителен, ибо будет захлебывается WiFi, т.к. на него ТВ-шный трафик тоже сыпется. Поэтому и приходится прибегать к извращениям. Протестировал на виртуалке предыдущий вариант (аплинк и ТВ в бридж, адрес получает бридж). Вроде более-менее работает, хотя не понимаю как. Будет время проверю на боевом железе. 5 февраля 2014 г., 22:34 пользователь Artem Chuprina r...@ran.pp.ruнаписал: Черноус Алексей - 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: Что тяжелее - внешний процесс или вызов библиотеки?
Oleksandr Gavenko gaven...@gmail.com 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: Что тяжелее - внешний процесс или вызов библиотеки?
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: 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 r...@ran.pp.ruнаписал: Черноус Алексей - 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: 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[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: [DONE] wml://security/2014/dsa-285{3,4,5}.wml
On Wed, Feb 05, 2014 at 10:45:35PM +0100, Lev Lamberov wrote: ... -pPedro Ribeiro from Agile Information Security found a possible remote -code execution on Horde3, a web application framework. Unsanitized -variables are passed to the unserialize() PHP function. A remote attacker -could specially-craft one of those variables allowing her to load and -execute code./p +pПедро Рибеёро из Agile Information Security обнаружил возможность удалённого А почему не Рибейро? Может лучше латинские имена оставлять? ... -pSeveral security issues have been corrected in multiple demuxers and -decoders of the libav multimedia library. The IDs mentioned above are just -a portion of the security issues fixed in this update. A full list of the -changes is available at +pВ мультиплексорах и декодерах мультимедиа-библиотеки libav были +исправлены несколько проблем безопасности. Идентификационные номера, указанные выше, представляют собой лишь часть +проблем безопасности, исправленных в данной обновлении. Полный список в данно_м_ обновлении -- To UNSUBSCRIBE, email to debian-l10n-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140206051452.GB23437@localhost.localdomain
