raspberry pi: make routes persistent with dhcpcd

routing decisions…

so, the other day I needed to enter a static route to my raspberrys route table the critter is running raspbian 9 (“jessie”). this version of debianesque linux uses dhcpcd for the network configuration.

you can find a whole lot of info on how to configure the box with a static ip address. however, there are few examples for configuring a static routing table entry that will persist after a reboot.

as we all know by now, you can enter a manual route using the command:

# /sbin/route add -net gw

where is the router on your local network behind which the target network with the netmask (the “/24”) is to be found!

this entry will be lost after a reboot. in order to make it persistent, you have to edit/create a so-called “exit hook”. that’s a file that gets executed by dhcpd at various occasions, e.g. after the network interface has been configured with a valid address.

here’s how to do it:

edit the exit hook file. the command will create it, if it’s not there already:

# sudo vi /etc/dhcpcd.exit-hook

add the routing command, just as you’d type it on the command line:

## adding the persistent route from the example above:
/sbin/route add -net gw

now, in order to activate the hook file, you can try:

# sudo service dhcpcd restart

for a definitive test issue the reboot command.

if something goes wrong, you can debug the dhcpcd hooks by editing the file /lib/dhcpcd/dhcpcd-run-hooks and change the line

: ${syslog_debug:=false}
: ${syslog_debug:=true}

you can then “tail /var/syslog” in order to see the debug output.

happy routing!

Chrome on Mac: solving the “this browser is managed by your organization” message.

The other day i had this message in my chrome settings: “your browser is managed by your organization”. well, it was actually in german language, so it’s more like this one:

starting with chrome version 73 this warning comes up if one or more of chromes built-in policies differ from the default settings.

so you google the problem and you may find some solutions … for windows! (gasp) — or you come across the ‘solution’ to simply suppress the message without fixing the real problem…

most of us are not part of a browser-managing organization. therefore it would be nice to see which policy elements are set. you can see them with the browser-internal url:


this should bring up something like this:

here we go again… wasn’t it months ago when you were fed up with that chrome cloud printing dialog?

you wanted apples’ standard dialog window with chrome! you wanted back control!! you wanted reven… – whatever!

so you updated the policy above (DisablePrintPreview=true) and lived happily ever after since… until now: “your browser is being managed by someone else!” – you want to get rid of that message, for zarquon’s sake!

the thing is, when you set the policy element back to “false”, this still counts as a modified policy.

you can set the propery back with this command in a terminal window and restarting chrome:

defaults write com.google.Chrome DisablePrintPreview -bool false

…and guess what shows:


ok, so setting the property to “false” obviously leads nowhere. the trick is, to delete the property like this:

defaults delete com.google.Chrome DisablePrintPreview

et abracadabra: after a chrome restart your browser belongs to you again. no evil corp controlling whatever sleazy (or not) policies are set.

jokes aside: this method is a good way to see if this policy you deleted is actually the reason for the nefarious message. if the message persists after deleting the policy, there’s still another policy active.

seriously, Apple?


Seriously, Apple? Seriously?

You know, people are actually using Pages to get some work done – and you don’t bother with a consistent converter across document versions?

And on top of that, the new Software is perfectly able to read the old document when I manually change the version number in the metadata! That’s BS.

Fuck you Apple!

System-Druckdialog in Chrome (Mac OS)

Chrome öffnet beim Drucken einer Webseite, oder eines eingebetteten Dokuments stets seinen eigenen Druckdialog. Seit heute habe ich das Problem, dass der Druckdialog für eingebettete pdf’s unterhalb des Dokumentes geöffnet wird und somit vom Bildschirm verschwindet.

Abhilfe: 1) größeren Monitor verwenden, oder 2) Chrome dazu überreden, den System-Druckdialog zu benutzen. Während Lösung 1 auch nach einem Systemupgrade noch sicher funktioniert, ist Lösung 2 ein wenig günstiger zu haben ;-)Chrome druckt

Folgender Befehl in einem “Terminal” Fenster veranlasst Chrome, seinen eigenen Druck-Dialog nicht zu verwenden:

defaults write com.google.Chrome DisablePrintPreview -bool true

ggfs. Chrome neu starten, und dann… Happy Printing!