DHCP_PROBE.CF(5)

📦
version 1.3.1 · 2 versions
, in alpine 3.24, debian trixie, ubuntu questing, ubuntu resolute, ubuntu stonking

💖 dhcp_probe.cf — the config file glow-up 💖

okay bestie, welcome to DHCP_PROBE.CF(5), aka the File Formats Manual page for the config file that runs your whole dhcp_probe era. this is part 1 of 3, so hydrate, sit pretty, and let's get into it 🌸

✨ NAME ✨

dhcp_probe.cf — bestie, it's literally the configuration file for dhcp_probe 💅

✨ SYNPOSIS ✨

/etc/dhcp_probe.cf

✨ DESCRIPTION ✨

so the file /etc/dhcp_probe.cf holds all the configuration tea that the dhcp_probe(8) daemon needs. dhcp_probe reads it when it first starts up, and again every single time it catches a SIGHUP signal. it's giving "i keep receipts" 💖

the location of this file defaults to /etc/dhcp_probe.cf, but no cap, you can override that with a command-line option passed to dhcp_probe(8). your file, your rules, your main character energy 👑

the file is a series of statements, one per line, periodt. every statement starts with a keyword, then one or more arguments (how many depends on which keyword you're using). keywords and arguments get separated by spaces or tabs. and here's the slay: statements can appear in any order, the program does not care, it is unbothered 💅

some keywords want an ethernet-address argument. those values have to be written in a form that ether_aton(3) recognizes. for example: 1:2:3:4:5:6 or 00:A5:b2:0:BB:c ✨

some keywords take an ip-address as a value. those have to be written in a form that inet_aton(3) recognizes. for example: 192.168.1.2 🌸

blank lines? ignored, ghosted, not even perceived 🙈 lines where the first non-blank character is a # are treated as comments. but heads up: trailing comments on statements are NOT supported — so don't be sneaky and put a # comment at the end of a real statement, it will not go how you think 😭

and because literally every keyword that's currently defined is optional, the file is allowed to be completely empty. however — it must exist. empty is fine, missing is a whole crisis 💀

✨ KEYWORDS ✨

here's the lineup, bestie. the keywords are as follows:

🌈 chaddr

the chaddr statement is optional, and it sets the value of the chaddr field in the request packets the program sends out. this value also gets used to compute the DHCP Client Identifier option in some of the request packets (by prepending x'01'). cute, right? 🎀

specify it like this:

chaddr ethernet-address

if you don't specify it, this value defaults to the Ethernet address that corresponds to the interface you specified on the commandline. easy 💖

you might wanna reach for the chaddr statement if that interface is also a DHCP client — that way, sending requests with the interface's own chaddr/DHCP Client Identifier won't step on that other functionality's toes. considerate queen behavior 🫶

if you do specify a value, be sure to specify a unicast Ethernet address that does not belong to any valid client on your network. like, fr fr, don't do it.

correctly-functioning BootP and DHCP servers that respond will send their responses to the chaddr address — or, in some cases, to the Ethernet broadcast address. so if you specify a value here and it's different from your interface's Ethernet address, the program is gonna have to put the interface into promiscuous mode to be sure it actually hears those unicast responses. it's giving eavesdropping but make it legitimate 👀

ngl, important note: the chaddr value does not affect the Ethernet source address of the Ethernet frames the program sends. two different things, don't conflate them bestie 💅

if you specify this value, you may also wanna specify the same value in the ether_src statement. see that statement's description for the full discussion (it's right below, keep scrolling 🦋).

the chaddr statement is REQUIRED if do_not_lookup_enet_and_ip_addresses is specified.

🌈 ether_src

the ether_src statement is optional, and it sets the value of the ether_src field in the Ethernet frames the program sends.

specify it like this:

ether_src ethernet-address

if you don't specify it, this value defaults to the Ethernet address corresponding to the interface you specified on the commandline. same deal as before ✨

if you do specify a value, be sure to specify a unicast Ethernet address that does not belong to any valid client on your network. yes, again. it's that serious.

note that this value does not affect the chaddr field or the DHCP Client Identifier option field in the request packets the program sends. nope, not even a little 🚫

if you already specified a chaddr value, you may also wanna specify an equal ether_src value. it's not strictly necessary, but the way that it works is: doing so causes any Layer 2 switches on the network to learn that this hardware address lives on your leg of the network. that means they won't have to flood response packets directed at that hardware address everywhere — they can just direct those response packets to your leg of the network only. targeted delivery, so efficient, we love her 🌟

bonus: specifying the same ether_src value could also help you discover any buggy BootP or DHCP servers that mistakenly send their responses to the sender's ether_src instead of to the sender's bootp_chaddr. catching bugs in 4K, no cap 🔥

the ether_src statement is REQUIRED if do_not_lookup_enet_and_ip_addresses is specified.

🌈 do_not_lookup_enet_and_ip_addresses

the do_not_lookup_enet_and_ip_addresses statement is optional. when it's not specified, the program will try to look up the Ethernet address of the network interface you named on the commandline. (it does this by querying the operating system for that info.) and to do that, it may need to first look up the IP address of that same interface. performing either of those operations may be troublesome on some interfaces or platforms. and if those lookups fail? that's a fatal error. no recovery arc 😭

specifying do_not_lookup_enet_and_ip_addresses tells the program: bestie, don't even try to look up the interface's Ethernet address and IP address. we're skipping that whole plotline 🙅

if do_not_lookup_enet_and_ip_addresses is specified, then both ether_src and chaddr must be specified. mandatory. non-negotiable. the girls that get it, get it 💅

also, specifying do_not_lookup_enet_and_ip_addresses may allow you to use this program on interfaces that are configured with no IP address at all. iconic flexibility 🦋

🌈 server_id

the server_id statement is optional, and it sets the value of the DHCP Server Identifier option in some of the request packets the program sends.

specify it like this:

server_id ip-address

if you don't specify it, this value defaults to 10.254.254.254 🌸

the DHCP Server Identifier option shows up in the packets the program sends when it's mimicking a DHCP client in the SELECTING state.

it's best if the DHCP Server Identifier option the program uses does not match the IP address of any valid DHCP server on your network — we're avoiding confusion here, bestie, protect the peace 🕊️ other than that, literally any IP address is a reasonable value; you may wanna pick one that could never be a valid address on your network. go wild, but go careful 💖

🌈 client_ip_address

the client_ip_address statement is optional, and it sets the IP address the program should request — or claim to already have a lease on. bold of her, honestly 👑

specify it like this:

client_ip_address ip-address

if you don't specify it, this value defaults to 172.31.254.254 ✨

when the program generates a DHCPREQUEST packet that mimics a DHCP client in the INIT-REBOOT or SELECTING state, that packet contains a Requested IP Address option holding this value. and when the program generates a DHCPREQUEST packet mimicking a DHCP client in the REBINDING state, that packet contains a ciaddr field holding this value. two flavors, same value, very consistent of her 💅

it's best that the value the program uses does not match the IP address of any valid DHCP client on your network — again, we're avoiding confusing valid DHCP servers. be kind to the servers 😌

and it's extremely useful if the value the program uses is not valid (topologically speaking) for the physical network the program is sending packets on. why? because sending a topologically inappropriate value may stimulate some DHCP servers to respond with a DHCPNAK — which helps the program flush out DHCP servers. yes bestie, we're being a little chaotic on purpose and it works 🔥

🌈 response_wait_time

the response_wait_time statement is optional, and it sets how long the program should wait for responses after sending a single request packet. patience is a virtue, but it's also a config value ⏳

specify it like this:

response_wait_time num_milliseconds

if you don't specify it, this value defaults to 5000 milliseconds (that's 5 seconds, for the math girlies 🧮).

the value is specified in milliseconds, and it must fit into an int on your host. (values larger than an int may be silently misinterpreted — no error, no warning, just vibes and wrongness 💀) typical values are on the order of a few thousand milliseconds, i.e. several seconds.

🌈 cycle_time

the cycle_time statement is optional, and it sets how long the program should sleep between each probe cycle. her little nap break 😴💖

specify it like this:

cycle_time num_seconds

if you don't specify it, this value defaults to 300 seconds.

the value is specified in seconds, and it must fit into an unsigned int on your host. (values larger than an unsigned int may be silently misinterpreted. same curse as before, bestie 🙈) typical values range from several hundred to several thousand seconds — i.e. several minutes to several hours. a long, luxurious nap 🌙

during each probe cycle, the program sends one of the request packet flavors, captures any responses that arrive during the response_wait_time, then repeats that for each of the other request packet flavors. after doing this for each flavor of request packet, the probe cycle is complete, and then the program sleeps for the cycle_time. a whole routine, she's got it down 🌈

the legal_server statement is optional, and it specifies the IP source address of responses that come from a legal BootP or DHCP server on your network. this statement may be specified multiple times. collect them all ✨

specify it like this:

legal_server ip-address

if you don't specify it, the program assumes there are no legal BootP and DHCP servers on your network — meaning every single response gets treated as coming from an unknown DHCP server. no one is above suspicion 👀

when the program receives a response packet, it compares that packet's IP source address against all the addresses you've specified in legal_server statements. if the IP source address matches one of those values, the response is deemed to have come from a known DHCP server and is ignored, ghosted, unbothered 💅 if the IP source address does not match any of those values (or you didn't specify any legal_server at all), then the program logs a message reporting the packet's IP source address and Ethernet source address. and on top of that, if the program was started with the -o commandline option, the packet also gets written to a packet capture file. receipts forever 📝

if both legal_server and legal_server_ethersrc statements appear, then a response must have both a valid IP source and a valid ethernet source to be considered as having come from a known DHCP server. two-factor authentication but for network vibes 🔐

more to come in part 2, bestie — don't go anywhere 🫶

When it's relaying a response from a server over to a client, some BootP Relay Agents are out here changing the response's IP source address — swapping the server's IP for their own. So if the BootP Relay Agents on your network are doing that, you need to list their IP addresses here instead. 💅

The legal_server_ethersrc statement is optional, and it's how you tell the program the Ethernet source address of responses coming from a legit BootP or DHCP server on your network. You can specify this statement as many times as you want. 👑

Specify it like this:

legal_server_ethersrc ethernet-address

If you don't specify it, the program just does not check the Ethernet source address of responses. Simple as that.

But if you have specified at least one legal_server_ethersrc value, then when the program gets a response packet, it compares that packet's Ethernet source address against all the addresses you listed. If the Ethernet source doesn't match one of them, the response is deemed to have come from an unknown DHCP server — and the program logs a message reporting the packet's IP source address and its Ethernet source address. And on top of that, if the program was started with the -o commandline option, the packet also gets written to a packet capture file. 📝

If both legal_server and legal_server_ethersrc statements show up, then a response needs both a valid IP source and a valid Ethernet source to count as coming from a known DHCP server.

Heads up bestie: every single router on the path from the DHCP server to the DHCP client is gonna overwrite the Ethernet source address field. So if you specify any legal_server_ethersrc statements, also list the Ethernet source value(s) for the last hop router(s). And a BootP Relay Agent on the path from the DHCP server to the DHCP client will overwrite the Ethernet field too — so also list the Ethernet source value(s) for the BootP Relay Agent. (The BootP Relay Agent is often co-resident in the last-hop IP router, so you might've already handled that when you listed the last-hop router(s).) 😌

The legal_server_ethersrc statement is considered experimental in versions 1.3.0 - 1.3.1, since it's only gotten limited testing. Not fully cooked yet, iykyk. 🙈

🦋 lease_network_of_concern 🦋

The lease_network_of_concern statement is optional, and you can specify it multiple times. It's how you specify one or more network ranges that are of concern relative to the IP addresses being handed out by a rogue BootP/DHCP server. 😤

Specify it like this:

lease_network_of_concern network-ip-address network-mask

Specifying one or more lease_network_of_concern statements activates the "Lease Networks of Concern" feature. ✨

So here's the vibe: when the program receives a response packet that it decides is from a rogue BootP/DHCP server, and the "Lease Networks of Concern" feature is active, the program digs into the packet a little further. If the packet's yiaddr field is non-zero, that value gets tested to see if it falls inside any of the "Leases Networks of Concern." If it does, then the message the program logs gets extended to also report that fact and to include the value of the yiaddr field. And furthermore, if an alert_program_name2 was specified, then when that program is called, it's called with an additional -y yiaddr option. (This is not supported if an alert_program_name was specified, because the older alert_program_name uses a syntax that can't be extended. rip to the old syntax honestly.)

Important: the "Lease Networks of Concern" feature does not change the way the program probes for or detects rogue BootP/DHCP servers. Once a rogue BootP/DHCP server is detected, the feature only may cause additional information to be added to the message logged (and passed to alert_program_name2). That's it, no cap.

So what's this actually for? Say you specify your networks' legitimate address ranges as "Lease Networks of Concern." Most rogue BootP/DHCP servers distribute private IP addresses, or send DHCPNAKs to legitimate clients — but other, more damaging rogue BootP/DHCP servers may distribute IP addresses that fall right inside your legitimate network ranges. This helps you tell those more damaging incidents apart from the more common ones. 💯

🎀 alert_program_name 🎀

The alert_program_name statement is optional, and it's how you specify the name of an external program that should be run every single time a response packet is received from an unexpected server.

Note: using the newer alert_program_name2 statement is preferrable. 👑

Specify it like this:

alert_program_name /absolute/path/name

Unexpected response packets get reported as a matter of course, and optionally written to a packet capture file. You can use an alert_program_name to provide additional handling of the event — like alerting an appropriate party via mail or paging, for example. 📬

The alert_program_name you specify gets called with four arguments, in this order:

  1. the name of the calling program (e.g. dhcp_probe)
  2. the name of the interface on which the unexpected response packet was received
  3. the IP source address of the packet
  4. the Ethernet source address of the packet
⚠️ Since the alert_program_name is called with the same privileges as dhcp_probe (i.e. root), you should exercise caution to make sure the alert program is safe for a privileged user to execute. Like, genuinely, be careful with this one. 🫶

And because the syntax supported by the external program isn't extensible, using alert_program_name2 is preferrable.

You may not specify both alert_program_name and alert_program_name2. Pick a lane bestie.

💜 alert_program_name2 💜

The alert_program_name2 statement is optional, and it's how you specify the name of an external program that should be run every time a response packet is received from an unexpected server. (Same job as the other one, but shinier. ✨)

Specify it like this:

alert_program_name2 /absolute/path/name

Unexpected response packets are reported as a matter of course, and optionally written to a packet capture file. You may use an alert_program_name2 to provide additional handling of the event — for example, to alert an appropriate party via mail or paging.

The alert_program_name2 you specify gets called with the following required options:

  • -p the name of the calling program (e.g. dhcp_probe),
  • -I the name of the interface on which the unexpected response packet was received
  • -i the IP source address of the packet
  • -m Ethernet source address of the packet

The following non-required options may also be passed:

  • -y the non-zero yiaddr value from the packet, when it falls inside a "Lease Network of Concern"

The alert_program_name2 program you specify must ignore options or arguments it doesn't recognize — this is to make sure it stays forward-compatible with future enhancements to dhcp_probe. It also must be prepared to accept options in any order. No assumptions, bestie.

⚠️ Same warning as before, and it still matters: as the alert_program_name2 is called with the same privileges as dhcp_probe (i.e. root), you should exercise caution to ensure that the alert program is safe for a privileged user to execute.

You may not specify both alert_program_name and alert_program_name2. Periodt. 💅

✨ EXAMPLE ✨

An example /etc/dhcp_probe.cf file follows:

# dhcp_probe.cf: config file for dhcp_probe
#
# General syntax:
#  Comment lines start with '#' (trailing comments not permitted).
#  Blank lines are OK.
#  Tokens within a line should be separated with spaces and/or tabs.
#  Entries in the file may be in any order.
#  Any 'ethernet-address' must be written in a form that ether_aton(3) recognizes; e.g.
#      1:2:3:4:5:6   00:A5:b2:0:BB:c
#  Any 'ip-address' must be written in a form that inet_aton(3) recognizes; e.g.
#      192.168.1.2
#
# ----------------------------------------------------------------------------------
#
# CLIENT HARDWARE ADDRESS
#
# By default, for the 'chaddr' field in the BootP header, we use the Ethernet
# address corresponding to the interface you specified.
# We also use this value to compute the DHCP Client Identifier option (by prepending x'01').
# You may optionally override this value.
# (Note that this does not override the Ethernet Src address in the Ethernet frame we send.)
#
# You might want to do this if our interface is also a DHCP client, so
# sending requests with the interface's own chaddr/DHCP Client Identifier would interfere with
# that functionality.
#
# If you specify a value, be sure to specify an Ethernet address that does not belong to
# any valid client on your network.  Be sure to specify a unicast Ethernet address.
#
# Syntax:
#    chaddr enet-addr

chaddr 0:0:0:1:2:3

# ----------------------------------------------------------------------------------
#
# ETHERNET SOURCE ADDRESS
#
# By default, for the 'ether_shost' field in the Ethernet header, we use the Ethernet
# address corresponding to the interface you specified.
# You may optionally override this value.
# (Note that this does not override the 'chaddr' in the BootP header, nor the DHCP Client Identifier.)
#
# If you are specify the 'chaddr' statement, you might want to also do this, so you don't miss buggy
# DHCP servers that respond (incorrectly) to ether_src instead of to chaddr.
#
# If you specify a value, be sure to specify an Ethernet address that does not belong to
# any valid client on your network.  Be sure to specify a unicast Ethernet address.
#
# Syntax:
#    ether_src enet-addr

ether_src 0:0:0:1:2:3

🆔 DHCP SERVER IDENTIFIER

Okay bestie, so when we build a DHCPREQUEST packet for a client that's sitting in the SELECTING state, the options field has to carry a DHCP Server Identifier option, and that option points at the IP address of the DHCP server the client is selecting. And here's the tea: it's best if the value we use doesn't match the IP address of any actual valid DHCP server, because otherwise we'd be out here confusing them for no reason. 😭

The program ships a default of 10.254.254.254, and you can override it right here.

Syntax:

server_id ip-addr

Example:

server_id 10.1.2.3

📍 CLIENT IP ADDRESS

So when we generate a DHCPREQUEST packet for a client in the INIT-REBOOT or SELECTING state, the options field must contain a Requested IP Address option — that's the IP address the client is requesting. And when we generate a DHCPREQUEST packet for a client in the REBINDING state, the ciaddr field in the BootP header must contain the IP address that the DHCP client presently has leased and wishes to renew. ✨

In all of these cases, it's best that the value we use not match the IP address of any valid DHCP client, so we don't go confusing the valid DHCP servers.

And honestly? It's extremely useful if the value we use is not valid (topologically speaking) for the physical network we're sending packets on. Sending a topologically inappropriate value may stimulate some DHCP servers into replying with a DHCPNAK, which helps us flush out DHCP servers. (This will probably only happen in response to the packets we send when we're pretending to be in the REBINDING state.)

The program provides a default value of 172.31.254.254, which you may override here.

Syntax:

client_ip_address ip-addr

Example (commented out, as-is):

# client_ip_address 172.31.254.254

⏳ RESPONSE WAIT TIME

After we send one packet, we wait for responses — and the length of time we wait is the response_wait_time. The program's default is 5000, and you can override it here. 💅

The value is measured in milliseconds, and it must fit into an int on your host. (Values larger than an int may be silently misinterpreted. 💀) Typical values are on the order of a few thousand milliseconds, i.e. several seconds.

Syntax:

response_wait_time num_milliseconds

Example (commented out, as-is):

# response_wait_time 5000

😴 CYCLE WAIT TIME

For each flavor packet, we send the packet and then listen for responses to that packet. Once we've done that for all the flavor packets, we go to sleep for the cycle_time, then repeat the whole process. The program's default is 300, and you may override it here. 🛌

The value is measured in seconds, and it must fit into an unsigned int on your host. (Values larger than an unsigned int may be silently misinterpreted. 🙈) Typical values range from several hundred to several thousand seconds — that's several minutes to several hours, iykyk.

Syntax:

cycle_time num_seconds

Example:

cycle_time 1200

After sending one packet, we wait for responses. Responses coming from legal BootP or DHCP servers get ignored — presumably you aren't interested in discovering them. 😌

You specify a legal server's IP source address with the legal_server statement. The value you specify gets compared to the IPsrc field in each response's IP header.

If you've got multiple legal servers, put each one in its own separate statement. And if your BootP Relay Agents overwrite the server's IP address in the IPsrc field with their own IP addresses, then you'll need to list the IP addresses of the BootP Relay Agents instead.

Alternatively — and this is a whole vibe — just don't specify any legal_server statements at all, so that no responses will be considered legal. (This is different from the way legal_server_ethersrc statements are handled, jsyk.)

If both legal_server and legal_server_ethersrc statements appear, then a response must have both a valid IP source and a valid ethernet source to be considered legal.

Syntax:

legal_server ip-addr

Examples:

legal_server 192.168.1.2
legal_server 192.168.3.4

You specify a legal server's Ethernet source address with the legal_server_ethersrc statement. The value you specify is compared to the ethernet_src field in each response's IP header.

Got multiple legal ethernet sources? One statement each, bestie. 📝 Every router on the path from the DHCP server to the DHCP client will overwrite the ethernet_src field — so also list the ethernet_src value(s) for the last hop router(s). And the BootP Relay Agent on the path from the DHCP server to the DHCP client will overwrite the ethernet_src field too — so also list the ethernet_src value(s) for the BootP Relay Agent. (This is often co-resident in the last-hop IP router, so you may have already taken care of this when you listed the last-hop router(s). ✨)

Alternatively, don't specify any legal_server_ethersrc statements at all. If none are specified, then all ethernet_src values are considered legal. (This is different from the way legal_server statements are handled, fr fr.)

If both legal_server and legal_server_ethersrc statements appear, then a response must have both a valid IP source and a valid ethernet source to be considered legal.

Syntax:

legal_server_ethersrc enet-addr

Examples (commented out, as-is):

# legal_server_ethersrc 0:2:4:ab:cd:ef
# legal_server_ethersrc 0:17:30:1:0A:3

🚨 ALERT PROGRAM NAME

Besides logging a response we received from an unexpected server, we will optionally call a user-specified "alert program" if one is specified here. To use this feature, give the absolute pathname of a program we should execute for each unexpected response. 🫶

You can specify it either with the older alert_program_name statement, or (preferably!) with the newer alert_program_name2 statement. (The newer one is preferable because it calls the alert program with a more extensible syntax.) You may not specify both alert_program_name and alert_program_name2. Pick a lane. 💅

Old style alert program:

Syntax:

alert_program_name /absolute/path/name

The program specified via alert_program_name will be called as follows:

/absolute/path/name  name_of_calling_program  name_of_interface_on_which_the_response_was_received  IP_source_of_the_response  ether_src_of_the_response

Newer style alert program:

Syntax:

alert_program_name2 /absolute/path/name

The program specified via alert_program_name2 will be called as follows:

/absolute/path/name  -p name_of_calling_program  -I name_of_interface_on_which_the_response_was_received  -i IP_source_of_the_response  -m ether_src_of_the_response [-y yiaddr_when_in_lease_networks_of_concern]

The options may appear in any order. The program must silently ignore any options or arguments it does not recognize, so as to be forward-compatible with future enhancements to dhcp_probe. (Future-proofing, we love to see it. 💖)

Example:

alert_program_name2 /usr/local/etc/dhcp_probe_notify2

🏠 LEASE NETWORKS OF CONCERN

Optionally, define one or more network ranges that are to be treated as being of special concern when a rogue BootP/DHCP server is detected sending a response that contains a yiaddr value falling into any of these ranges. 👀

Specify each such network range of concern in a separate statement. When the yiaddr value in a rogue server's response falls into any of these ranges, the message logged will contain additional text remarking on this fact. And if an alert_program_name2 is used, that alert program will be called with an extra option so it can also act on that fact. 🌸

If you specify all your networks' legitimate IP ranges, this can help you take additional notice of rogue BootP/DHCP servers that distribute your network addresses — rather than simply distributing private IP addresses or sending DHCPNAKs to legitimate clients.

Syntax:

lease_network_of_concern  IP-network-address network-mask

Examples:

lease_network_of_concern 128.112.0.0 255.255.0.0
lease_network_of_concern 140.180.0.0 255.255.0.0

🎀 MISCELLANEOUS

If the do_not_lookup_enet_and_ip_addresses statement is specified, the program will not try to look up the ethernet address of the network interface specified on the commandline. (That, in turn, may also require the program to look up the IP address of that network interface.) Specifying this can allow the program to run on some platforms and interfaces where one of those lookups would fail. 🔥

Heads up bestie: if this is specified, both ether_src and chaddr must also be specified.

Example:

do_not_lookup_enet_and_ip_addresses

👀 SEE ALSO

dhcp_probe(8)

And that's a wrap on this config file, bestie!! 🎉 This iconic page came to you courtesy of Princeton Univ., dated Jan 18 2021, and it's the DHCP_PROBE.CF(5) manual page. Go configure something beautiful. 💅✨👑

📦 where this page comes from