| 1.1, Аноним (-), 15:02, 04/02/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
IPv6 prefix delegation всё так же несовместим с ppp-интерфейсами? Или исправили наконец?
| | |
| |
| 2.2, Xasd (ok), 15:17, 04/02/2014 [^] [^^] [^^^] [ответить]
| +4 +/– |
 > IPv6 prefix delegation всё так же несовместим с ppp-интерфейсами
у меня -- работает нормально.
конфигурационный файл для DHCP -- генерируется на лету -- скриптом /etc/ppp/ipv6-up.d/99-my-internet.sh ..
(а не прописывается заранее статически... ведь заранее мы не знаем даже номера для ppp-интерфейса. он может оказаться ppp0,ppp1,ppp2,ppp3,ppp4 -- так что заранее прописать конфиг-файл -- точно не возможно)
в файле /etc/ppp/ipv6-down.d/99-my-internet.sh --- происходит останов DHCP и удаление его конфигурационного файла.
----------------------------------------
это я говорил не про DHCPD , а про DHCPCD :-)
----------------------------------------
а при самой работе сервера DHCPCD -- при событии получения IPv6 Prefix (или при событии изменения этого префикса) -- динамически создаётся конфигурационный файл для RADVD , и запускается RADVD
(раньше времени запускать RADVD -- нельзя -- так как в этом случае RADVD может "заснуть" и уже не реагировать на то что появился новый префикс)
вобщм сложный костыль :) , но работает отлично :)
----------------------------------------
по хорошему -- нужно было бы написать одного демона-манагера, который бы всё время висел бы в памяти (учитывал бы актуальное состояние) и управлял бы всеми этими DHCPCD и RADVD и их конфигурационными файлами (запускал бы, останавливал бы, создавал конфиг, удалял конфиг)..
а производил бы это своё управление --- исходя из информации о поступающих событиях:
-- появился новый pppX интерфейс
-- разъединился pppX интерфейс
-- появился IPv6 PD Prefix
-- изменился IPv6 PD Prefix
-- продлился (без изменений) IPv6 PD Prefix
-- удалился IPv6 PD Prefix
| | |
| |
| 3.3, Аноним (-), 16:37, 04/02/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> это я говорил не про DHCPD , а про DHCPCD :-)
Спасибо, попробую dhcpcd. А то сабжевый dhclient при попытке получения префикса на ppp выдаёт «Unsupported device type 512 for "ppp0"». Сколько ни мучился, так и пришлось откапывать и собирать древний и неподдерживаемый wide-dhcpv6 как единственный, о котором до меня дошли "истории успеха". Будет время - попробую переделать на dhcpcd.
| | |
| |
| 4.7, Xasd (ok), 17:44, 04/02/2014 [^] [^^] [^^^] [ответить] | +1 +/– | а вот я даже не пробовал использовать wide-dhcpv6 слишком уж не стандартное оно ... большой текст свёрнут, показать | | |
| |
| 5.20, Аноним (-), 04:42, 05/02/2014 [^] [^^] [^^^] [ответить]
| +/– |
Как обычно, в хучшем виде - три страницы простыней с конфигурацией размазанной по всему коду. А потом такие удивляются - за что мы инит не лю. За то что там за такими как этот тип приходится расчищать...
| | |
| |
| 6.26, Xasd (ok), 14:58, 05/02/2014 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Как обычно, в хучшем виде - три страницы простыней с конфигурацией размазанной по всему коду.
это не код, а весёлый костыль. :-)
если ты захочешь этот костыль разбить на отдельные маленькие файлы -- то всё равно это ОСТАНЕТСЯ костылём -- но при этом ещё и будет находиться РАЗМАЗАННО внутри файловой системы...
(охринитально будет: файловая система будет усеяна мини-костылями! ну круто же! ещё больше непонятно-как связанных файлов! ещё сложнее система!)
уж пусть лучше костыль находится в одном файле. потому что это нормально, когда всё говно собрано в одном месте :) ..
а чтобы УСТРАНИТЬ костыльность этого кода (а не размазать говно по файловой системе) -- нужно сделать дополнительный сервис (запускаемый из systemd), который будет висеть в памяти и заниматься своей работой (а именно какой работой (?) заниматься согласованием сервисов: PPPD, DHCPCD, RADVD).
об этом я уже писал. см сообщение #2 (нижняя часть сообщения)
| | |
|
|
|
| 3.4, pavlinux (ok), 16:49, 04/02/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
 Таджикские админы! :)
Если так приспичило разруливать ppp, то делается бридж и все динамические линки суются в него.
| | |
| |
| 4.5, izyk (ok), 17:05, 04/02/2014 [^] [^^] [^^^] [ответить]
| +/– |
 Точно. И ppp в бридж засунем, наш бридж, не такое может.
Молодец!
| | |
| 4.8, Xasd (ok), 17:51, 04/02/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> Таджикские админы! :)
на самом деле -- некоторые люди -- вообще думают что:
1. ppp-интерфейс это якобы всегда ppp0 (во всех скриптах хардкодно прописывается ppp0)
2. интернет якобы всегда имеет стабильный канал, и якобы всегда не рвётся (или если рвётся, то якобы только на 1 минутку, а не на 4 часа), и всегда подключается с первого раза (особенно с первого раза -- если компьютер в процессе своей загрузки). и т д ...
а если серъёзно подумать и учесть сколько разных может быть разных не стандартных нюансов -- вот тогда и приходит в голову написать демона-манагера (висящего в памяти, для целей разруливания всё как надо), про который я упомянул сообщения #2 (в низу) :-)
------------------------------------------------------------
> Если так приспичило разруливать ppp, то делается бридж и все динамические линки
> суются в него.
ну а про bridge -- интересная мысль , спасибо за пищу для размышления , только как тогда получить site-local IPv6 при событии поднятия интерфейcа pppX
# UPDATED!
кажется я понял как получить site-local IPv6 если бы он был bridge .. надо ещё подумать :) [ну и вообще -- думать полезно, да]
| | |
| |
| 5.9, izyk (ok), 19:03, 04/02/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> # UPDATED!
> кажется я понял как получить site-local IPv6 если бы он был bridge
> .. надо ещё подумать :) [ну и вообще -- думать полезно,
> да]
Вы действительно, думаете, что, ppp можно засунуть в bridge?
>> Таджикские админы! :) | | |
| |
| 6.11, Xasd (ok), 19:19, 04/02/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> Вы действительно, думаете, что, ppp можно засунуть в bridge?
а почему это должно не получиться? (ни разу не пробовал, разумется)
потому что "протокол точка-к-точке" ?
| | |
| |
| 7.15, izyk (ok), 22:15, 04/02/2014 [^] [^^] [^^^] [ответить]
| +/– |
Потому, что, есть теплое, а есть мягкое.
А если серьезно, попробуйте, или изучите, что есть что, и почему.
Для ленивых:
http://osdir.com/ml/linux.network.bridge/2008-06/msg00026.html
| | |
| |
| |
| 9.23, izyk (ok), 10:23, 05/02/2014 [^] [^^] [^^^] [ответить] | +/– | Да вы батенька, не только сомоуверенный , но еще, и не умеете признавать свои... текст свёрнут, показать | | |
| |
| |
| 11.27, izyk (ok), 16:28, 05/02/2014 [^] [^^] [^^^] [ответить] | +/– | Это точно Речь идет о Point-to-Point Protocol и его реализации в Linux Мо... текст свёрнут, показать | | |
|
|
|
|
|
|
|
| 4.21, Аноним (-), 04:43, 05/02/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> то делается бридж и все динамические линки суются в него.
Ого, да ты хакир? :)
| | |
|
| 3.10, Аноним (-), 19:08, 04/02/2014 [^] [^^] [^^^] [ответить]
| –2 +/– | |
>по хорошему -- нужно было бы написать одного демона-манагера, который бы всё время висел бы в памяти (учитывал бы актуальное состояние) и управлял бы всеми этими DHCPCD и RADVD и их конфигурационными файлами (запускал бы, останавливал бы, создавал конфиг, удалял конфиг)..
Тс-с, тихо, а то Поцтеринг услышит ;) Лучше пусть этот демон рулит сетевыми делами, а не всем в сиситеме.
| | |
| |
| 4.12, Аноним (-), 20:26, 04/02/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> Тс-с, тихо, а то Поцтеринг услышит ;)
Ага, и еще одним костылем станет меньше. Вот ведь изверг - последнее отнимает!
| | |
| 4.29, Аноним (-), 17:11, 05/02/2014 [^] [^^] [^^^] [ответить]
| +/– |
> Тс-с, тихо, а то Поцтеринг услышит ;) Лучше пусть этот демон рулит
> сетевыми делами, а не всем в сиситеме.
Без поттера никакого демона вообще не будет, потому что феерический костыль на шелле - это юниксвей.
| | |
|
|
|
| 1.6, Аноним (-), 17:18, 04/02/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> Поддержка стандартной реализации динамического DNS-сервер (DDNS), соответствующего актуальным требованиям RFC 4701, 4702, 4703 и 4361 и предоставляющего возможность совместного использования записей DDNS между клиентами DHCPv4 и DHCPv6.
А в BIND такая поддержка есть?
| | |
| 1.16, Аноним (-), 01:12, 05/02/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Кто нибудь знает, поддерживается ли failover при работе в режиме ipv6?
| | |
| |
| 2.19, Аноним (-), 03:04, 05/02/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> Кто нибудь знает, поддерживается ли failover при работе в режиме ipv6?
Какой еще фейловер для dhcp сервера ты хочешь? Достаточно хранить лизы в месте, доступном обоим серверам, а там уже до кого клиент раньше добежит. Никакой специальной поддержки не требуется.
| | |
| |
| 3.22, Аноним (-), 06:23, 05/02/2014 [^] [^^] [^^^] [ответить]
| +/– | |
Ну, я сейчас так и использую его, dhcpd6.leases лежит на glusterfs, pacemaker следит за состоянием демона dhcpd6. И это ни разу не круто.
В ipv4 режиме фейловер то нормально работает, если его еще не сделали для ipv6, то думаю скоро должны это реализовать...
| | |
| |
| 4.24, Аноним (-), 13:33, 05/02/2014 [^] [^^] [^^^] [ответить]
| +/– |
> Ну, я сейчас так и использую его, dhcpd6.leases лежит на glusterfs, pacemaker
> следит за состоянием демона dhcpd6. И это ни разу не круто.
Зачем pacemaker? Ну упадет у тебя один dhcp-сервер, все запросы другому достанутся, они же мультикастовые, никакого переключения не требуется.
| | |
| |
| 5.30, Аноним (-), 20:56, 05/02/2014 [^] [^^] [^^^] [ответить]
| +/– |
Просто pacemaker у меня уже рулил другими сервисами. Конечно ради одного dchpd его ставить не очень хорошая идея)
| | |
|
|
| 3.28, Аноним (-), 17:08, 05/02/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> Какой еще фейловер для dhcp сервера ты хочешь? Достаточно хранить лизы в месте, доступном обоим серверам, а там уже до кого клиент раньше добежит. Никакой специальной поддержки не требуется.
Что, и никаких race condition не возникает?
| | |
|
|
| 1.31, Денис (??), 19:06, 06/02/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
о, ребят, может кто поможет
[br]
костыльно наверное, но
[br]
есть /48 подсеть, хочу в зависимости от маков рассовать в 3 разные /64 подсети
[br]
завел shared-network, в ней 3 subnet6 по /64, в них pool6 с allow known-clients; deny unknown-clients, в каждом pool6 своя group в которой определены host {} с идетификацией по маку(добавил и по uid, после прочтения манов)
[br]
так вот статику получают только чуваки с маками из первого pool6, все остальные(те, что определены во втором и третьем пуле) получают динамику из первого пула
[br]
параллельно работает dhcpd -4, там такая штука прокатывает - все получают статиту в том пуле, в котором описаны host
[br]
сломал голову, как его заставить смотреть дальше первого пула :(
| | |
|
