Thirty-second upgrade guide for people who hate using diff
Upgrading important pieces of software can be a scary process, and not just because new versions introduce new behaviours and the possibility of new bugs. No, perhaps the greatest threat (assuming you can trust the project's maintainers to not be clueless and you've done your research on what's changed) is that you'll miss copying that magical config file value that made your network actually work.
Fortunately, staticDHCPd makes that easy: just copy your old conf.py file into the new version and you're good to go. Any omitted options are supplemented by sane defaults, new scriptable features are defined passively (you only use what you need), and you can add references to new options when you actually need them. It really couldn't be any friendlier... until it was: starting with 1.6.1, if you install the system using setup.py, your old config directory will be left intact, meaning that you just have to pull code, run setup, and go.
Installation instructions: Run install.sh with privileges that can create content in /etc and /usr/local/bin. Follow the resulting on-screen text to integrate the server with your OS's daemon-management engine.
Just remember to set up conf.py and everything should just work. Before
installing the server, though, run through the five-minute quickstart
described below; it doesn't require that you make any permanent changes to
your host.Five-minute "does this really work?" setup guide for busy administrators Uses sqlite3 or INI files to avoid unnecessary installations
(If you need more information, see the project page at http://uguu.ca/puukusoft/staticDHCPd/ or http://code.google.com/p/staticdhcpd/)
Step 1: Gather resources You need the code, which came with this lovely text file, and a computer on which to run it. Since this is a Unix-formatted file, you've probably already got that, too. You'll also need sqlite3 to manage the DHCP database. Chances are it's already installed, but check anyway. (Also Python 2.5+, but no modern Unix-like system is without that)
The last thing you need is enough access to bind to the DHCP ports.
Since there's no way you're going to just run this server on a production
box without testing it first, you've almost certainly satisfied this
requirement, too.
So you're done. That was easy.Step 2: Set up the DHCP database (This example assumes your network is similar to that of a typical home user; if this is not the case, you will need to adjust things, but you probably wouldn't be playing with a DHCP server if you were a typical home user anyway)
The example values below will give the MAC 'aa:bb:cc:dd:ee:ff' the IP
'192.168.0.197' and no hostname. You'll notice that non-host-specific
parameters are inherited from its subnet-classification, specifically
things like lease-time and basic routing parameters. DNS, NTP, and
other properties aren't specified in this example, but are in the samples/
directory.
(The term "subnet" is used loosely here: the only thing that matters is that
the "subnet" and "serial" values match for inheritance -- you could put
"floor 3" in as a "subnet" if you wanted to. The term "subnet" was chosen
because it seemed like the most likely classification system for
administrators to use and recognise)
INI method:
Create a file with the following contents; the name is up to you.
[192.168.0.0/24|0]
lease-time: 14400
gateway: 192.168.0.1
subnet-mask: 255.255.255.0
broadcast-address: 192.168.0.255
[aa:bb:cc:dd:ee:ff]
ip: 192.168.0.197
subnet: 192.168.0.0/24
serial: 0
SQLite method:
Open a terminal and run `sqlite3 dhcp.sqlite3`
Copy and paste the contents of samples/sqlite.sql into the prompt.
Now that your database is ready to go (SQLite is easy!), add some rules.
INSERT INTO subnets (
subnet,
serial,
lease_time,
gateway,
subnet_mask,
broadcast_address,
ntp_servers,
domain_name_servers,
domain_name
) VALUES (
'192.168.0.0/24',
0,
14400,
'192.168.0.1',
'255.255.255.0',
'192.168.0.255',
NULL,
NULL,
NULL
);
INSERT INTO maps (
mac,
ip,
hostname,
subnet,
serial
) VALUES (
'aa:bb:cc:dd:ee:ff',
'192.168.0.197',
NULL,
'192.168.0.0/24',
0
);Step 3: Edit conf.py Copy 'conf/conf.py.sample' to 'conf/conf.py'.
For now, since you'll want to see everything that goes on, set DEBUG to
True; 'True' must be capitalized. (In production, DEBUG should be False,
since it adds a little bit of overhead and it may fill system logs very
quickly)
Also set DAEMON to False. If you don't, it'll do daemonsy things, which
aren't good for helping to identify configuration problems quickly.
Then set LOG_FILE to point at your home directory. We'll be running this
test using your privileges so you don't have to create a special role
account, to save time. (In production, though, you'll definitely want to
lock this thing down, just like every daemon: long-running root processes
are bad)
Set PID_FILE to point at the same directory as LOG_FILE.
Run `id` in a terminal; this will tell you what your uid and gid are; enter
these values under UID and GID to restrict staticDHCPd's privileges.
Run `ifconfig` and make note of your IPs; set DHCP_SERVER_IP and WEB_IP
accordingly. If you only have one IP, enter it in both fields.
INI method:
After that, set DATABASE_ENGINE to 'INI'; capitalization matters.
Lastly, set INI_FILE to point at the file you created in step 2.
SQLite method:
After that, set DATABASE_ENGINE to 'SQLite'; capitalization matters.
Lastly, set SQLITE_FILE to point at the file you created in step 2.Step 4: Start the server
Run sudo python staticDHCPd.
You should see a few lines appear, explaining that the server is now
running.
Tell the device with the MAC given in step 3 to request an address and
everything should Just Work(tm).
Go to http://<WEB_IP>:30880/ to see what the server's been doing.Step 5: Kill the process When satisifed that the system works, hit ^C or send SIGTERM (15) to the process.
You now have proof that what you have in your proverbial hands is a functional, fully static DHCP server.