I’m running EOS on this machine and Arch on another. I’m setting up Arch as best I can and finding that, in addition to the ArchWiki, just poking around how EOS is setup has proven to be “educational”. Case in point: configuring sudo. My Arch machine has an “admin” account and a “guest” account. So, after doing a little reading, I decided the best thing to do was add my admin to the “wheel” group and then give that group access to sudo (using visudo of course). Once I confirmed it was right, I disabled root login so that a “guest” user could neither use sudo nor log in as root via the su command.
.
Anyway, once I had that setup, I wanted to see how EOS did it. At first, I was a bit confused because it looked like anything that would add a user or group as a sudoer was still commented out when I ran visudo. Then I saw the last line. It points to a directory that you can’t access unless you’re root and, within that directory is a short text file that adds sudo access to the wheel group.
.
I presume that’s more secure than what I did on Arch. Neat trick… 
drop-in files = no pacnew files for the original file, as it was not modified.
I also learn much better by disassembling first. It was hugely beneficial both in cars, and computers.
Welcome!
I don’t know if it is more secure or not but using drop-in config files is a more modern approach whenever an application/service supports it.
It allows for a more modular and self explanatory result than modifying a monolithic config file.
I now get this. Got the “sudoers.pacnew” on my Vanilla Arch machine and and, after brining it over to “sudoers”, I had to go in and uncomment the line giving sudo access to the wheel group. Minor deal but, had I put a little file with that command in /etc/sudoers.d like EOS does, I wouldn’t have to make any manual updates at all.
Makes more sense now.