Messages

See https://forum.opnsense.org/index.php?topic=15224.0 but question still remains about the best method to interrupt the established connections - though I am more confident of my choice of method now.

Currently OPNsense only backs up it's xml configuration and not other, shall we say, less standard, configuration and functionality changes. I view this as a minor deficiency, but a minor deficiency for which I'd like to contribute.

See these forum threads for similar concerns:
https://forum.opnsense.org/index.php?topic=10631.msg48436#msg48436
https://forum.opnsense.org/index.php?topic=13220.msg60839#msg60839

In my particular situation, a restored backup would leave two dangling, self-created services that would not be easily recreated (if not for the guts having been posted on this forum). What I would like to see introduced is one of the two following methods.

The simplest would be a tar.gz backup scheme with a customization directory that mirrors the layout of /usr/local/opnsense/{scripts,service/conf/actions.d{,(*?)}}. Coming from a Linux background, my immediate suggestion is /usr/local/etc/opnsense, but I suspect that is probably not correct, nor have I yet determined whether configd can handle a second service directory (and even this could be overcome with a simple copy at startup, but that's sloppy at best IMO). Assuming configd can put to use a second actions.d directory (I haven't looked into the mechanism yet, but presumably there is an include statement someplace to pickup the ini-style files), I could probably slap a patch together in a couple of hours.

The other, more complex, but seemingly more inline with the goals and methods outlined in the Development Manual, would be to extend the xml to include both customized scripts and actions (and presumably to extend the GUI to account for these). I haven't looked into this at all yet. One problem that comes immediately to mind is that I only want to read these and apply to disk when a change is made or upon initial restore, but not at startup (as alluded to in the previous suggestion, this would be sloppy IMO). I'm guessing that this is probably already handled elsewhere looking at the SSL certificates for instance, but it is a concern if it is to be done correctly. Suggestions for the xml would be appreciated.

I wanted to see first, if there was any interest in the above suggestion, and second, if something is already planned for this type of change. I also want to know if there is a more appropriate forum for discussion and intent to work toward this goal. Of course, I am open to other view points on this topic, but from my limited POV (I've only been using OPNsense for about a month or so, and I absolutely love it), a working solution seems really as simple as selecting one of the two choices above and working toward it.

Thoughts on the above? Thanks in advance for your direction, suggestions, discussion, concerns, answers to the above questions, and most importantly, this excellent product.

--DJ

Okay, so I setup a policy to shut off my kids televisions at 10:00 PM (it gives them an hour to go to sleep after bed time) and it was not working as expected (they would still be working well after 11:00 and eventually stop working sometime late into the night). This was due to long lived connections. I added a script that effectively does: `pfctl -k 0.0.0.0/0 -k roku1.home.mydomain.com && pfctl -k roku1.home.mydomain.com && pfctl -k roku2...` and added this into cron jobs (in the GUI by creating a service) with "5 22 * * 0-4" which ultimately does achieve the desired outcome, but I was wondering if there is a way to do this from the GUI. I wasn't able to find one, so I just made it work for now, but it would be really nice if these types of custom scripts were exportable as part of a system backup (or maybe they are and I'm just not aware of it, scripts were stored in roots home directory).

So, just to bring a completed example, after copying MyCert.crt and MyCert.key via ssh to root's home directory, I clobbed together the following script:

#!/bin/sh

UNIQID=`/usr/local/bin/php -r "echo uniqid();"`
DATE=`date +%Y%m%d`
CRT="/root/MyCert.crt"
PRV="/root/MyCert.key"
FIRSTLN=`grep -m1 -n "<cert>" /conf/config.xml | cut -d ":" -f 1`
DESCR="My Certificate $DATE"

if test -f $CRT; then
  mkdir /root/certtemp
  cd /root/certtemp
  CRTE=`cat $CRT | /usr/bin/openssl base64`
  PRVE=`cat $PRV | /usr/bin/openssl base64`
  DESC="<descr>$DESCR</descr>"
  CERT=`echo "<crt>$CRTE</crt>" | tr -d '\n'`
  PRIV=`echo "<prv>$PRVE</prv>" | tr -d '\n'`
  REFID="<refid>$UNIQID</refid>"
  PATERN="\\n    $REFID\\n    $DESC\\n    $CERT\\n    $PRIV\\n  <\\/cert>\\n"

  echo "    $REFID" > temp.txt
  echo "    $DESC" >> temp.txt
  echo "    $CERT" >> temp.txt
  echo "    $PRIV" >> temp.txt
  echo "  </cert>" >> temp.txt
  echo "  <cert>" >> temp.txt
  cp /conf/config.xml config.xml
  sed "${FIRSTLN}r temp.txt" config.xml > config.xml.tmp
  sed "s@<ssl-certref>.*</ssl-certref>@<ssl-certref>${UNIQID}</ssl-certref>@" \
      config.xml.tmp > config.xml.new
  cp $CRT cert.pem
  cat $PRV >> cert.pem

  cp /conf/config.xml /conf/config.xml.$DATE
  cp config.xml.new /conf/config.xml
  cp /var/etc/cert.pem /var/etc/cert.pem.$DATE
  cp cert.pem /var/etc/cert.pem

  /usr/local/etc/rc.restart_webgui

  # Cleanup
  cd /root
  rm -rf certtemp/
  rm $CRT
  rm $PRV

  echo "New certificate $DESCR installed."
else
  echo "Nothing to do. Exiting."
fi

This seems to work well enough. Bad me! I exceeded my weekly certs by not using the LE test environment. Obviously, this needs to be tested after my punishment (a week), but it worked locally. If anybody sees something bad, please speak up.

Thanks.

--DJ

To complete this for the archives:

Certs themselves are located in /conf/config.xml at <opnsense><ca><cert><refid/><desc/><crt/><prv/>...

Probably obvious, but the text that is inserted into the GUI is base64 encoded in the crt and prv fields (from CLI `cat file | openssl base64`), desc is the plain text description, and the refid value is php's uniqid (from CLI `php -r "echo uniqid();`).

The refid field is earlier used in the Web GUI config at <opnsense><system><webgui><protocol>https</protocol><ssl-certref/>

Okay, so that's easy enough - and probably easier if I spoke PHP. :-)

Only really dumb question remains. :-) How to restart/reload webgui from CLI?

--DJ

Thank you hbc! Exactly what I was looking for.

--DJ

To answer my own question...the active cert and the key are concatenated at /var/etc/cert.pem. Where the source for this file is stored after adding to the GUI, I do not know. Whether I can simply overwrite this file, I am unsure.

Using a wildcard cert from LE, this is generated on another host for several internal domains. While I can certainly do via GUI, I'd rather add this into the existing process like the rest of my internal hosts. I've searched for a bit, dug through the file system (after uploading manually), but to no avail. Any pointers to docu?

Thanks.

--DJ