Bitácora

2013

2012

Wigner

DNS

• Modified /opt/cfmgr/dns/input/skeleton/named.conf-header to listen to 188.185.1[67].0/28
• Modified /opt/cfmgr/bin/cfmgr_modules/dns2.pm to include ws-servers in the internal view
• Modified /opt/cfmgr/bin/cfmgr_modules/dns/dnslogging.pm to include ws-servers in the internal view
• Added /opt/dns/namedb/named.ca and /opt/dns/namedb/null.zone on new servers

dns6

Links

• DNS and Naming Issues
• ISP ip6 reverse DNS

RADIUS

HP MAC Auth

• HP is using CHAP for Mac Authentication. This is not a problem providing the attribute User-Password is defined.
• The request sourced by HP uses attribute Service-Type = Call-Check while 3Com uses Service-Type = Framed-User.
• huntgroups are selected based on the Service-Type, so we need to modify cfmgr's radius.pm so that TN switches are selected when Call-Check is received. We need to maintain multiple Service types since telnet (NAS-Prompt-User) is also used to send privilege level information for telnet sessions.

TN  NAS-IP-Address == 172.18.128.4, Service-Type == Framed-User
TN  NAS-IP-Address == 172.18.128.4, Service-Type == Call-Check

DHCP

Auto Registration

Requirements

From the minutes of the meeting concerning the definition of the project

-----Original Message-----
From: Miguel Marques Coelho Dos Santos 
Sent: Tuesday, March 20, 2012 5:11 PM
To: Jose Carlos Luna Duran; Carles Kishimoto Bisbe; Andreu Belmonte Pena; Eric Bonfillou; Olof Barring; Gavin Mccance; 
Jean-Michel Jouanigot; Tim Bell; Gavin Mccance; David Gutierrez Rueda; Miguel Marques Coelho Dos Santos
Cc: Bernd Panzer-Steindel; Wayne Salter
Subject: notes on 'arrival of new hardware' discussion

Dear all, 

brief summary of today's meeting.

We went over the process and tried to run through different scenarios in order to find a solution that fits and is generic.

The standing proposal is to:
1. Have a network service proving via DHCP private IP addresses to unknown MAC addresses.
1.1 Some tests will have to be done for the different IPMI setups (same switch, different switch, etc)
2. Use the private IP to PXE boot
3. Query "landb" giving a list of MAC address of a server, and getting {network service,port} information as response 
4. Call landb with registration of server {hostname, MAC, serial, network service, port} 
5. Server is registered, network config can be reloaded to use routed IP

Besides this chain a few other things will have to be tested:
a. the IPMI registration, and how it impacts the use of the pool of private addresses
b. the DHCP lease time for the private addresses
c. a change of a NIC (MAC address) on a already registered server

Cable numbers are something we can probably live without. Server location too, i.e. rack name.
Security, how to delegate the rights to do the calls. The server should only have the rights to add itself anyway. 
Server should not be able to delete entries from landb.

Next steps:
- CS to estimate changes in landb
- setup a test "switch" with necessary services and configuration
- agree on SOAP calls (do point 3 and 4 on top cover it?)

DHCP Implementation

• A boolean attribute will be defined ('DynamicPool') that will be true for services used by the installation process. This will allow to extend the service to different locations of the network without modifying the HCP code.

• Services with this attribute will contain a pool (distributed among the servers) with a 60 minutes lease and the next configuration:

              pool {        
                  max-lease-time 3600;
                  min-lease-time 3600;
                  default-lease-time 3600;
              # Don't assign IP addresses to PSUs or other devices. Only DHCP
                  deny dynamic bootp clients;
                  allow unknown-clients;
              # Implicit deny all
                  range 10.41.1.4 10.41.1.126;
              }

• known and unknown clients: If a host is declared with a fixed address, with independence of the service from where the DHCP requests are coming, the host will be considered known.

• not authoritative: When a client requests a lease outside of the server's pool, no answer will be sent. The client will eventually give up the lease and move to INIT state.

• authoritative: The server will not generate NACKs for leases outside of its pool. If the host is defined and a lease of the pool is requested a NACK will be sent back.

          Network administrators setting up authoritative DHCP servers for their networks should always write authoritative; at  the  top  of
          their  configuration  file to indicate that the DHCP server should send DHCPNAK messages to misconfigured clients.   If this is not
          done, clients will be unable to get a correct IP address after changing subnets until their old lease has expired, which could take
          quite a long time.

• Moving from unknown to known

          DHCPREQUEST for 10.41.1.10 from 00:0b:5d:93:a7:b1 via 137.138.20.145: lease 10.41.1.10 unavailable.
          DHCPNAK on 10.41.1.10 to 00:0b:5d:93:a7:b1 via 137.138.20.145
          DHCPDISCOVER from 00:0b:5d:93:a7:b1 via 137.138.20.145
          DHCPOFFER on 137.138.20.146 to 00:0b:5d:93:a7:b1 via 137.138.20.145
          DHCPREQUEST for 137.138.20.146 (137.138.175.208) from 00:0b:5d:93:a7:b1 via 137.138.20.145
          DHCPACK on 137.138.20.146 to 00:0b:5d:93:a7:b1 via 137.138.20.145

• Deployment
  • The dynamic pool will be divided in two halves and two different configuration files will be generated
  • CVS repository needs to be modified to store every server version

Set ALLOWWEBVIEW = CsMembersGroup