Re: dhcp-users Digest, Vol 81, Issue 15

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: dhcp-users Digest, Vol 81, Issue 15

James Beedy

> On Jul 15, 2015, at 10:28 AM, [hidden email] wrote:
>
> Send dhcp-users mailing list submissions to
> [hidden email]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.isc.org/mailman/listinfo/dhcp-users
> or, via email, send a message with subject or body 'help' to
> [hidden email]
>
> You can reach the person managing the list at
> [hidden email]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dhcp-users digest..."
>
>
> Today's Topics:
>
>   1. Permissions spec & Neutron driver (James Beedy)
>   2. Re: Permissions spec & Neutron driver (Simon Hobson)
>   3. Re: No Option 43 in DHCP ACK (Jason Bailey)
>   4. Re: PD broken in v4.3.2? prefix6 start prefix is outside the
>      subnet (Chris Buechler)
>   5. dhcpd-pools / other leses management tool (Leandro)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 15 Jul 2015 08:42:59 -0700
> From: James Beedy <[hidden email]>
> To: [hidden email]
> Subject: Permissions spec & Neutron driver
> Message-ID:
> <[hidden email]>
> Content-Type: text/plain; charset="utf-8"
>
> Hello,
>
> I am implementing an ISC DHCP server driver for the Openstack Neutron
> project. My goal is to create a python module that controls, and allows
> multiple instances of ISC DHCP server to run under multiple different
> users. It would be nice if there was a spec that detailed the constraints
> concerning permissions of groups, users, directories and files associated
> with the ISC DHCP server....as of right now I am playing a lot of guess and
> check, hopefully this is something you might be able to shed some light on.
> I am currently experimenting with running different instances of ISC DHCP
> server each in a chroot environment, but would like to not have to create a
> separate container or chroot for each instance of ISC DHCP server running
> on a box. I?m sure there is a more efficient way, I just am unfamiliar with
> the permissions spec. Any insight to the permissions associated with ISC
> DHCP server would be extremely appreciated. Also, is an ISC DHCP neutron
> driver something the ISC team has thought about, or possibly already has in
> the works somewhere?
>
> Thanks in advance for your insight,
>
> James
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20150715/fe52ccec/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 15 Jul 2015 17:06:58 +0100
> From: Simon Hobson <[hidden email]>
> To: Users of ISC DHCP <[hidden email]>
> Subject: Re: Permissions spec & Neutron driver
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=windows-1252
>
> James Beedy <[hidden email]> wrote:
>
>> I am implementing an ISC DHCP server driver for the Openstack Neutron project. My goal is to create a python module that controls, and allows multiple instances of ISC DHCP server to run under multiple different users. It would be nice if there was a spec that detailed the constraints concerning permissions of groups, users, directories and files associated with the ISC DHCP server....as of right now I am playing a lot of guess and check, hopefully this is something you might be able to shed some light on. I am currently experimenting with running different instances of ISC DHCP server each in a chroot environment, but would like to not have to create a separate container or chroot for each instance of ISC DHCP server running on a box. I?m sure there is a more efficient way, I just am unfamiliar with the permissions spec. Any insight to the permissions associated with ISC DHCP server would be extremely appreciated.
>
> With the caveat that I'm neither a programmer nor an expert in this area ...
> I think you'll find that the server really doesn't need many permissions at all. With one exception, it needs to be able to read it's config file, write it's PID file, and write/re-write it's lease file - with all that, it doesn't need any privileged access to anything (so basically the appropriate read & write permissions to the files/directories it needs to work in).
>
> What it does need is the ability to handle raw sockets. So it needs to be able to take packets off the wire which can't be handled by the IP stack, and send packets directly which can't be sent via the IP stack. This is probably the only privileged access it needs.
>
> The other issue is that you can only run one instance per interface, and there are some reports that it doesn't "play nice" with VLANs. I'm not sure of the details, but IIRC when it's come up, there have been issues of tagged packets being picked up by a server listening on an untagged interface of a trunked port.

Awesome. Thanks for your insight!

>
> ------------------------------
>
> Message: 3
> Date: Wed, 15 Jul 2015 10:55:56 -0600
> From: Jason Bailey <[hidden email]>
> To: Users of ISC DHCP <[hidden email]>
> Subject: Re: No Option 43 in DHCP ACK
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>
> Calix ONTs, actually. I'm trying to get only certain ONTs to pick up
> certain option 43 configuration directives.
>
> Their documentation says:
>
> Configure the default global DHCP options at the DHCP server as follows:
> option space CALIX-ONT-SERVER;
> option CALIX-ONT-SERVER.cms-address code 1 = ip-address;
> option CALIX-ONT-SERVER.second-tftp-address code 2 = ip-address;
> option CALIX-ONT-SERVER.syslog-address code 4 = ip-address;
> option CALIX-ONT-SERVER.firmware1 code 101 = text;
> option CALIX-ONT-SERVER.firmware2 code 102 = text;
> option CALIX-ONT-SERVER.firmware3 code 103 = text;
>
> Configure specific values for DHCP options within a subnet declaration,
> as shown in the following example:
>
> # AE-ONT Management Network
> subnet xxx.xxx.xxx.x netmask xxx.xxx.xxx.x{
> vendor-option-space CALIX-ONT-SERVER;
> option CALIX-ONT-SERVER.cms-address xxx.xxx.xxx.xxx;
> option CALIX-ONT-SERVER.syslog-address xxx.xxx.xxx.xxx;
> option CALIX-ONT-SERVER.firmware1 "blah";
>
> The problem is, that doesn't work (I couldn't get to work, anyhow). If
> you use class matching, the DHCP server will send option 43 information,
> but unfortunately (as far as I see it, anyway), only if those classes
> are declared globally. The problem with that is that the matching ends
> up being all encompassing and ONTs end up getting options that they
> shouldn't. In short, it creates severe issues on the network.
>
> If I could do class matching per subnet (i.e. at the subnet level), that
> would fix my problems. I just don't see how to do that.
>
> Jason
>
>
> On 07/14/2015 01:56 AM, Maarten Carels wrote:
>>> On 13 Jul 2015, at 20:42 , Jason Bailey <[hidden email]> wrote:
>>>
>>> Hi all,
>>>
>>> I'm trying to troubleshoot a problem with DHCP option 43. I've defined the vendor option space and declared the vendor specific options per the vendor's documentation, but I'm not getting any results.
>>>
>>> The device (DHCP client) is sending options 53 (request), 60 (vendor class ident), 61 (client identifier), 43 (vendor specific info) , 55 (parameter request list), among a few others. Option 55 includes 43 (vendor specific info) in addition to the usual items (like subnet mask, router, etc). The server is sending an ACK, but it doesn't include any of the option 43 items I've defined.
>>>
>>> In my DHCP server config, I've defined "option space XYZ" and "option XYZ.item code 1 = ip address". I've also configured defined "vendor-option-space XYZ" and "option XYZ.item 1.2.3.4" inside the subnet declaration (the entire subnet has been created entirely for the same type of devices, so there's no need to match only a certain type of devices (i.e. device class))
>>>
>>> dhcpd -t doesn't complain about any issues in my config file, and there are no issues in the log (I'm using 'log-facility local7').
>>>
>>> I'm at a loss at the moment, so any help is greatly appreciated. I'm running ISC DHCP 4.1.1 on CentOS 6.6.
>> I guess this is for the cisco wireless stuff.
>> I use this:
>> option space Cisco_LWAPP_AP;
>> option Cisco_LWAPP_AP.server-address code 241 = array of ip-address;
>>
>>
>> subnet 192.168.31.96 netmask 255.255.255.224 {
>> option routers 192.168.31.97;
>> vendor-option-space Cisco_LWAPP_AP;
>> option Cisco_LWAPP_AP.server-address 192.168.31.250;
>>
>> pool {
>> failover peer "kantoor-draadloos";
>>
>> # most fixed
>> range 192.168.31.118 192.168.31.119;
>> }
>> }
>>
>> Works for me (Internet Systems Consortium DHCP Server 4.3.1 on Debian 7.8)
>>
>> ?maarten
>>
>>
>> _______________________________________________
>> dhcp-users mailing list
>> [hidden email]
>> https://lists.isc.org/mailman/listinfo/dhcp-users
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20150715/e6764f34/attachment-0001.html>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 15 Jul 2015 12:23:55 -0500
> From: Chris Buechler <[hidden email]>
> To: Users of ISC DHCP <[hidden email]>
> Subject: Re: PD broken in v4.3.2? prefix6 start prefix is outside the
> subnet
> Message-ID:
> <[hidden email]>
> Content-Type: text/plain; charset=UTF-8
>
> On Wed, Jul 15, 2015 at 3:59 AM, Christian Kratzer <[hidden email]> wrote:
>>
>> a couple of quick points on this:
>>
>> 1. this would require one to enlargeng the access network to emcompass
>> the whole pool of prefixes one wishes to delegate. This would definetely
>> be considered a broken design.
>>
>
> Yes, especially considering there's no reason the PD subnet needs to
> be even close to the interface's subnet. As things stand now after
> that change, in some circumstances you'd need a subnet6 2000::/3 or
> close to it for PD to work.
>
>
>> 2. Just having the network large enough would still only route towards
>> the net.  This would not help with getting the ultimate next hop for the
>> assigned prefix resolved.
>>
>> 3. ipv6 relay agents on routers that support PD sniff the traffic and
>> transparently add the route to the delegated prefix to the correct next hop.
>>
>> Such a change would definetely be broken and would have to be backed out.
>>
>
> Yes, agree.
>
>
> On Wed, Jul 15, 2015 at 12:17 AM, Shawn Routhier <[hidden email]> wrote:
>>
>> However I do think you are confused about the configuration file
>> showing class support from the KB article.  I have tried the three
>> configuration files in that kb article and all of them seem to work
>> correctly for me with the prefixes being within the subnet.
>>
>
> Correct, the issue is where they're outside the subnet, sorry I wasn't
> clear on that part.
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 15 Jul 2015 14:28:40 -0300
> From: Leandro <[hidden email]>
> To: Users of ISC DHCP <[hidden email]>
> Subject: dhcpd-pools / other leses management tool
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> Hi dhcp users list.
> Im looking for some tool to list the provided leases and its status.
> So far I can list range usage per defined network using dhcpd-tools as
> follows:
>
> [root@centos-dns1 etc]# dhcpd-pools -L11 -c /etc/dhcp/dhcpd.conf -l
> /var/lib/dhcpd/dhcpd.leases
> Ranges:
> shared net name     first ip           last ip            max cur
> percent  touch   t+c  t+c perc     bu  bu perc
> Relay1              192.168.88.2     - 192.168.88.126     125 0
> 0.000     40    40    32.000     50   40.000
> Relay2              192.168.88.130   - 192.168.88.254     125 0
> 0.000      1     1     0.800      0    0.000
> Relay1              192.168.89.2     - 192.168.89.126     125 0
> 0.000     66    66    52.800     59   47.200
> Relay2              192.168.89.130   - 192.168.89.254     125 0
> 0.000      1     1     0.800      2    1.600
>
> This is very usefull , but I wonder if is there other way to list all
> leases and its status, for example pfsense provides the following list:
> P address <https://10.0.0.251/status_dhcp_leases.php#> MAC address
> <https://10.0.0.251/status_dhcp_leases.php#> Hostname
> <https://10.0.0.251/status_dhcp_leases.php#> Start
> <https://10.0.0.251/status_dhcp_leases.php#> End
> <https://10.0.0.251/status_dhcp_leases.php#> Online
> <https://10.0.0.251/status_dhcp_leases.php#> Lease Type
> <https://10.0.0.251/status_dhcp_leases.php#>
> 192.168.88.130 08:00:27:95:d9:62
> <https://10.0.0.251/services_wol.php?if=opt2&mac=08:00:27:95:d9:62>
> 2015/07/15 14:21:06 2015/07/15 16:21:06 offline active
>
>
> Thanks
> Leandro.
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20150715/42ab7406/attachment.html>
>
> ------------------------------
>
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
> End of dhcp-users Digest, Vol 81, Issue 15
> ******************************************

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

signature.asc (859 bytes) Download Attachment