Messages

Do you want to try a PR in update.git?

Sure, I can have a stab.

We could make opnsense-update a bit more helpful by adding a check if the origin is there (and script minimal recovery with it)?

Sounds fair. Maybe even an early check for file locks on config.xml in opnsense-revert so it can bail before that becomes an issue?

"Wrong" would be an overstatement. The issue is expressed better as the more that happens before the sample confs are reinstated - and refresh.sh does quite a bit - the greater the chance that things can go wrong before they are reinstated.

That's what happened in my case. refresh.sh is run pretty early in the post-install chain, and in my case is where it hung (as I said, I understand due to a file lock on config.xml likely causing reconfigure to stall). So it never got to reinstating the sample confs before I was forced to abort.

We have a few spots already... yet... installing a package will render both OPNsense.conf and FreeBSD.conf so where do the files get lost except when the core package is gone (which is vital so pkg isn't supposed to remove it).

Here? https://github.com/opnsense/core/blob/master/Keywords/shadow.ucl#L47

(which picks up https://github.com/opnsense/core/blob/5a5350e29ead5cea9c3160d618833552ecde9f4d/plist#L2567-L2569)

My understanding of the logic is that the script goes through pre-deinstall then post-install. Maybe the solution is to move the sample confs copying to earlier in the post-install chain.

3. We forcefully disable FreeBSD repo since a few years on firmware configure.  We can't avoid user console fiddling with that neither, but at least preserve the integrity the system still has after the fact.

I guess what I am trying to do is have a failsafe where the script aborts in between /usr/local/etc/pkg/repos/FreeBSD.conf being removed during the script's process (so the disable override is gone), and refresh.sh re-copying back the sample confs. Without that failsafe, the disable override isn't there when opnsense-revert or an update is run again, and so the system falls back to using /etc/pkg/FreeBSD.conf. This is what happened in my case. When I re-ran opnsense-revert after the first abort, I received an error about package conflicts (can't recall the exact message), and was prompted to reinstall/upgrade pkg. Not realising that this was because the FreeBSD repo was being used, I did that, and this led to my troubles.

The point being: re-enabling of the FreeBSD repo was not caused by "user console fiddling".

@franco, perhaps a trap could help in the scenario that I faced? At the very least the user would be returned to a stock repo configuration, rather than a broken one.

Code Select Expand

--- a/src/revert/opnsense-revert.sh
+++ b/src/revert/opnsense-revert.sh
@@ -30,6 +30,24 @@ if [ "$(id -u)" != "0" ]; then
  exit 1
 fi
 
+REPOSDIR="/usr/local/etc/pkg/repos"
+
+recovery()
+{
+ if [ -f "${WORKPREFIX}/.recovery" ]; then
+ # post-install scripts may not have completed;
+ # attempt full reconfiguration first, fall back
+ # to restoring repo defaults if config.xml is
+ # not accessible (e.g. held by another process)
+ if ! timeout 30 /usr/local/etc/rc.configure_firmware; then
+ for CONF in $(find ${REPOSDIR} -name '*.conf.sample'); do
+ cp ${CONF} ${CONF%.sample}
+ done
+ fi
+ rm -f "${WORKPREFIX}/.recovery"
+ fi
+}
+
+trap recovery EXIT
+
 WORKPREFIX="/tmp/opnsense-revert"
 WORKDIR=${WORKPREFIX}/${$}
 PKG="pkg-static"
@@ -93,6 +111,8 @@ done
 for PACKAGE in ${@}; do
  # reset automatic, vital as per package metadata
  AUTOMATIC="1"
+
+ touch "${WORKPREFIX}/.recovery"
 
  if [ -n "${COREPKG}" -a "$(echo "${COREDEP}" | grep -c ${PACKAGE})" != "0" ]; then


The expanded view ofcourse :)

Ah, if you mean simply the expanded view in the sidebar, that should be doable. I will look into it.

I don't see how that could be sensibly changed. Only leaf menu items (Users in this case) actually have a page associated with them, the parent menu items are just group headings. So there is nothing opening them in a new tab is actually able to show, hence the behaviour.

I can't say for 100% sure, but I am pretty sure that it can be done, however I am not a webdeveloper so I could be horribly wrong! :)

Yes, anything in theory can be done, but it still comes back to the question - what would the new tab show?

Example :

- System
-- Access
--- Users

Only Users can be opened in a New Tab ;)

Mouse/Touchpad Middle Click or CTRL+Click = Open link in New Tab.

Got it. I don't see how that could be sensibly changed. Only leaf menu items (Users in this case) actually have a page associated with them, the parent menu items are just group headings. So there is nothing opening them in a new tab is actually able to show, hence the behaviour.

In my opinion, the biggest problem with the menu is that you can "middle click" to nothing. If you have not reached the last level of the menu with the actual settings...

Not sure I understand what you mean by this?

Disabling automatic menu collapsing in my mind would quickly lead to a monstrosity.

I agree - I would never use the toggle xD

As a separate proposal, I was also contemplating adding a toggle setting that could disable automatic menu collapsing generally. I think the scroll would probably still need to happen though.

https://github.com/opnsense/core/pull/10033

Yes, as I said. It was not me who enabled it though. This only occurred when I had to abort the opnsense-revert script. Somehow that caused the OPNsense repo to be disabled and the FreeBSD repo to be enabled

The further alternative, which is probably the cleanest (but a little more challenging to implement).