The direct answer is "No". The notion of "master file" only concerns that example, and refers to the "salient path name" encoded into the automatic setup script. (As you know, that example is not ideal in my view, with the automatic setup attached to and repeated with any and all interface(s) coming up.)

iptables-persistent instead enshrines the path names /etc/iptables/rules.v4 and /etc/iptables/rules.v6 as being its "master files".

Hmm, by attaching the loading of table rules to the event(s) of bringing up an interface, you probably make life a little bit difficult for yourself. It's not "wrong" per se, and probably the only major complication is that in a typical set up, the network interfaces are brought up by udev in the pre-pivot boot up stage.

If that is your case, you will need to ensure that the rules files are included in your initrd, as well as the iptables-restore program and its dependencies (libraries). (I believe the if-pre-up.d script gets pulled in to the initrd automagically when remaking initrd).

Or alternatively, make that not be your case by not letting udev start networking. I.e., remove all "allow-hotplug" phrases from /etc/nework/interfaces. Possibly use "auto <if>" phrases instead, which tells the post-pivot networking init script that "these are yours, mate", or if then you also have a separate network manager, you'll need to leave all song and dance to it.

EDIT: I see from your other post that you're using wicd, so my thought about udev is probably not applicable here. Maybe it's enough to make your script exit more promptly when lo is brought up; or even tie it explicitly to $IFACE=wlan0.

Yes, according to FSSTND, you'll need to venture off the ranch for that one.

Fair enough. If you are in the mood for tinkering, it's not really a difficult thing to start an X program over slim. The fundamental aspects are to have the XAUTHORITY and DISPLAY properly set when starting the program, and to start the program at the right time, i.e., after slim.

I don't have florence but can illustrate using xvkbd instead.

For example, it might be sufficient to add a line into your /etc/rc.local file, making it look like this at the end:

( sleep 5 ; XAUTHORITY=/var/run/slim.auth DISPLAY=:0 /usr/bin/xvkbd ) &
exit 0

That line supposedly will start the virtual keyboard xvkbd upon reboot, after 5 seconds, on top of the slim login splash.

You will need to adjust as appropriate for florence of course.

Note that (assuming it works) the virtual keyboard only comes up after reboot, and not again when you log out. But maybe that is sufficient.

Since I (and you?) don't have cups, disabling it for cups is not a solution.

I managed to get the (standard) ASCII 4.9.0-4-amd64 kernel to avoid loading parport and friends by having boot parameter

lp=none

together with blacklisting:

# echo blacklist parport > /etc/modprobe.d/blacklist-parport.conf
# echo blacklist parport_pc >> /etc/modprobe.d/blacklist-parport.conf
# update-initramfs -u

It needs both kernel parameter and blacklisting. Possibly lp=0 would work as well, but I couldn't bother testing it.

btw if you care about  IEEE Registration Authority, a "locally administered mac address" needs bit 2 of first byte set and bit 1 cleared. Thus "5e" would be better than "5c".
see eg http://www.noah.org/wiki/MAC_address

Ideally you should insert the locking program before the suspend action as otherwise it'll wake up unlocked until the locking starts. For example:

if [  "$3" = "close" ] ; then
     DISPLAY=:0 su -c "xtrlock -b" ralph &
     /usr/bin/obsession-exit -s
fi

Note also that (afaik) the lid button script is run by acpid as root and not "the DE user", so a sudo isn't needed, but some way to ensure GUI access is. The added command line above includes the two parts of making the locking program (xtrlock) have the right $DISPLAY set up, and (via su) be the right user (for my laptop).

A smaller footprint  solution would simply read byte triplets from /dev/input/mice, where <9,0,0> means left button down, and <8,0,0> means left button up; all other triplets mean other things. I would use newlisp, of course, to remain in small foot print scripting, but a small C program could also do.

Sorry. I lost interest there. Too many words. To paraphrase Ramsey: "What you can't say in just a few words, you should whistle.".

To be clear, ICMP is a protocol and not a port; it's the Internet Control Message Protocol, whereby routers may exchange meta-data about IP level connectivity. There are several networking protocols to consider, both within the IP class (such as in particular TCP and UDP), and outside the IP class (in a range of varying obscurity).

As said before, there is no such thing as "invisible" on the Internet, short of not being connected at all. But there is a gray scale of "protection layers" of setting blockages for certain network traffic, depending on how you want your host to handle it. I'.e., like the rules you showed on top, which indeed tells the host to drop certain incoming ICMP packets, rather than deliver them to their normal handling (by the kernel). I think you'd do well in dropping IGMP as well, and then consider blocks for TCP and UDP messaging, which offer the majority of intentionally harmful networking.

You can install eudev=220:3.2.2-devuan1 from experimental on Jessie, but you need to make sure to also install libudev1=220:3.2.2-devuan1, which is its companion (despite the name).  The latter might be noted as a downgrade (relative jessie-backports), but that's nothing to worry about.