Kea: (((Modern))) DHCP

but it can. true and false return boolean values.

ok kiddo. you won.

Oh and they push this shite on the download page for good old DHCPD

Attached: wew.png (888x686, 195.53K)

...

get with the times, grandpa

...

...

Just use SqLite.

y tho?

Because you don't have to have any extra operations burden and it is insanely well tested.

Sounds overengineered.

Now that's Web Scale™

% file /usr/bin/true/usr/bin/true: Mach-O 64-bit executable x86_64%
It'd be easier to take him seriously if he hadn't become an irredeemable Machomo.

don't you understand, user? this is the "modern" way of doing things. It's ""modern"" to have to run a database for a simple standard service instead of just using a text file. It's """Modern""" to integrate your infrastructure with (((Facebook))), goyim! It's """"Modern"""" to not do that icky Free Software thing and be Open Source. Locking certain features behind a restrictive licensing paywall is just part of business! It's """""MODERN""""" to retain data to give it to your friendly neighborhood CIAnigger. It's """"""MODERN"""""" to have a subscription model and support contracts for a DHCP daemon. It's """""""MODERN""""""" to have emojis because emojis are so cool and trendy WOOO IM A MODERN ADMIN WHERES MY SOYLENT?!?

Attached: M O D E R N.jpg (1200x900, 162.18K)

DHCP is basically a webscale protocol in the first place.

...

DHCP is a protocol defined by RFCs. ISC DHCPD and Kea are "Unix network-related software" written in the UNIX languages C and C++. DHCPD is a great example of how much C sucks. It has its own memory manager with its own strings because C's suck. Its configuration file has its own expression evaluation language. It uses a text file as a log-structured database because that's the UNIX way. None of this bullshit has anything to do with the DHCP protocol itself and there is other DHCP software.
isc.org/wp-content/uploads/2017/08/dhcp41conf.html
isc.org/wp-content/uploads/2017/08/dhcp41eval.html
isc.org/wp-content/uploads/2017/08/dhcp41leases.html

An SQL database is a better choice for a database than a text file. Weenies use "shell script database programs" with text files and all that bullshit.

AT&T's PDP-11 ran out of disk space.

If UNIX was modular, they would be able to specify a lack of shell without that bullshit. They probably assumed every user was going to be logged into the PDP-11 and typing at a terminal, so they never bothered.

DHCPD lease file already is a database.

This statement is automatically added to the top of new lease files bythe server. It indicates the internal byte order of the server. Thispermits lease files generated on a server with one form of byte orderto be read by a server with a different form. Lease files which do notcontain this entry are simply treated as having the same byte order asthe server reading them. If you are migrating lease files generatedby a server that predates this statement and is of a different byteorder than the your destination server, you can manually add thisstatement. It must proceed any lease entries. Valid values for thisparameter are little-endian and big-endian.
I thought these lease files were "plain text." Why does plain text depend on byte order?

You speak of 'Un*x' as if was some complete and well formedentity, particularly when it comes to networking (which wasonly glommed on in recent history).I just loved that what AT*T sold as the "Basic NetworkingUtilities" package was UUCP! Basic Networking, yeah right.For g*ds sake, RFC1 is dated 1969, before Un*x was evenstarting taking up disk space.Funny thing about your subject line is that who am i | sed 's/\!.*//'is almost certainly the most portable command line to returnthe current hostname!!

That's why we have C -- a language designed to make everymachine emulate a PDP-11. That's why we have a file systemthat forces every file to be viewed as a sequence of bytes(after all, that's what they are, right?). That's why"protocols" depend on byte-order.They have never separated the program from the machine. Itnever entered their tiny, pocket-protectored with acalculator-hanging-from-the-belt mind.

I can think of a couple of use cases where managing dhcp records and leases in a database makes sense. Think of organisations with large numbers of devices which need to be under tight control but also managed by staff with little privileges, or by web interfaces. Universities, companies, datacentres...>>964554

What's wrong with openbsd's dhcpd?
nothing

Binary lease files are garbage just like binary log files are garbage.

It's a stripped version of ISC dhcpd. Unless I'm mistaken the lease file fills infinitely until the daemon is restarted. It lacks some features like ddns and the classless static routes option. Those are bloat though, I use it myself.

My isp dhcp is already pozzed. I can no longer IP jump without having to completely restart my wireless modem. I used to be able to with just disconnecting my network wan

Thanks for the heads up, I just migrated my config to OpenBSD's version.
If no glaring missing config option shows up, I'll be removing it.

This shit shines of NSA Project like a fullmoon on a deserted island.

...how?
Because it's new?
Because you're too stupid to understand the use-cases?
Because you couldn't explain what DHCP stood for if you were pop quizzed on it?

Dynamic Host Configuration Protocol
Now go fuck yourself, CIAnigger

I wasn't asking you to quote Google, faggot

$ file /usr/bin/true/usr/bin/true: POSIX shell script, ASCII text executable$ cat /usr/bin/true#! /bin/shexit 0$ unameNetBSD
benis

in what world are you calling /bin/true without also loading a shell? Surely systemd is doing it via C and wouldn't call /bin/true, SysV are already spawning shell scripts.

It seems like you're creating an extremely rare use case.

spot the difference

Attached: e3c3f2d3b8cd73f3aedd50f79dfc7d0a21b89c6b1119d1d42829f6aaeb75bb36.jpg (1200x900, 173.5K)

And the remedy was turning a zero-byte file into a C binary?

Any of you ever run a large dynamic network? It's tiring to automate parsing a single massive file for reservations and bootp images or ranges. Dnsmasq was better than windows but those are it for Enterprise.

...

Lmao. Every time I see you Cfaggots suggesting sqlite just because it can be called from C it grinds my gears.

Stop smoking SICP pages,
didn't mentioned C calls.

Why do you have to be such sensationalist faggots? Not every shitty product needs a thread.

Or you can just use odbc and let the end-user decide their database.

It has nothing to do with C brainlet, there are sqlite bindings for every language under the sun. The reason sqlite should be used is because it's small and bullet proof. It can be statically linked with your application and doesn't require the installation of yet another service.

For an application like this there is no justification for asking the user to install some bullshit like MySQL.

you mean "make". The vast majority of users will not be pleased to learn they are expected to set up a database themselves instead of having the software just fucking work.

Any scheme worth it's salt is going to have sqlite support.

No, I mean "let". A configurable system that uses sane defaults is a thing. It would be trivial to package a sqlite ODBC driver and default to it when the user doesn't override it with their own.
Don't be retarded. Having something configurable doesn't have to mean that the user is forced to configure it or it doesn't work.

No, make. Because in order to install software that's using bullshit like mysql instead of sqlite, the user must first install mysql. Giving the user the option between mysql, postgress, or any other database they want is still making the user choose one of them.

And yet that's not done, nor what you proposed originally before confronted over the UX disaster you were recommending.

If we accept the premise that plain text files are no longer adaquate, there is still no legitimate reason a DHCP server would need anything more than sqlite.

I honestly can't decipher what you are trying to argue. I suggested using ODBC, packaging a SQLite ODBC driver, and defaulting to a local SQLite database. No configuration out of the box, it just works, because it loads in SQLite and just runs with it. The user doesn't have to choose shit.
If you want to configure the server to use MySQL or Postegres, they override that setting, change the connection string to point to a local ODBC driver, and it works against that database instead.

How is this a "UX disaster"? What's such a disaster about using sane defaults that work out of the box and allowing the user to override them if they wish? That's what the vast majority of servers of every kind already do.

There are legitimate reasons if the DHCP server is being used in a corporate environment and needs to activate auditing hooks in the database, or if the DHCP needs to work against a RADIUS server for accounting purposes.

What is the problem with what I'm suggesting? Out of the box, it is exactly the same as just using SQLite and being done with it. It only is more work and complication if the user chooses to configure it. What's the specific downside? How, specifically, is a configuration option that doesn't need to be set a "UX disaster"? I have a strong suspicion that you aren't a programmer nor a sysadmin and don't actually know what you're talking about.

Because every additional configuration option is another code path to build, test, and support indefinitely. This can quickly grow to become unmanageable and spiral out of control. Offering a single, well-tested configuration that's guaranteed to work avoids the inevitable disappointment and brand damage that comes from users expecting arbitrarily complex custom configurations to "just work" out of the box -- definitely a UX disaster. Anyway, if you need a feature, you can always submit a patch or fork, that's the beauty of Open Source.

It's an ODBC connection string. You're overselling how much complexity is there. Programming against ODBC isn't a hell of a lot more complex than programming against SQLite, and it would be about the same amount of code to test. You don't have to test every driver that the users might want to use, just the ones you ship. You aren't responsible for user plugin failure.
And no thanks on submitting a patch. This isn't normal FOSS, it's a corporate product with an open core. I'm not donating my time and effort to make a corporate offering more appealing. I'll donate time and money to FOSS projects that are written by and for the public, or I'll work on a corporate product for pay. I'm not donating my time and money to develop a company's product for them.