Parts of setup & possible suggestion

Help with Setup/Upgrade
1

I’ve been looking at the setup scripts to dig into my Roundcube questions at first, and have a couple of questions:

It looks like the installation of the various components, outside of needing functions.sh and probably a few others, could be done individually in order to repair something. For instance, if I wanted to fix a roundcube installation, at the same version level, without risking or touching anything else, what are the problems in just running webmail.sh by putting in a selection method (like a menu or using a commandline parameter) in start.sh? That way the proper vars will get set up, then just one component gets reinstalled.

I haven’t looked exhaustively at it, but it looks like maybe and would need someone more sure of all the code to know if it could work…

Second, I’m curious why system.sh ends in this way:

restart_service fail2ban

systemctl enable fail2ban

Why the mixed service methods? Why not

systemctl enable fail2ban
systemctl restart fail2ban

or

update-rc.d fail2ban enable
service restart fail2ban

or both if unsure of what facility is available or test for which is available and pick one?

2

restart_service is a function that calls itself another function that hides the output of the command unless an error occurs.

So if I had to guess, I’d say restart_service fail2ban is meant to be a final check that fail2ban actually starts properly before it gets enabled.

3

Thanks, but that isn’t really the question.
The question is why the mixed methods?

The function restart_service uses the ‘service’ method as I pointed out, but is followed by a systemctl method. On some systems both exist, while older ones may not have systemctl. Not sure if service has been dropped anywhere yet…

So why enable using one format/method and restart using another method? Both enable and restart exist in either way of doing things. It just seems odd and possibly have a higher likelihood of failing on some systems this way.
OR
what am I missing as the benefit of mixing them?

4

I don’t know, maybe this function existed before systemd was introduced in Ubuntu and they never bothered to change it, or it was copied from somewhere…

Well, yes, but since MaiB is only supported on Ubuntu 22.04, where service still works as an alias for systemd, it doesn’t really matter, does it? :wink:

EDIT. Just tested it, and service fail2ban restart still works even on on 24.04.

5

If it’s done intentionally, if it has some benefit, it matters in that I and others could benefit from the understanding why that’s a good way to approach similar situations…

If it’s just something that still works and wasn’t updated to all systemd methods (it still works today), then it could get overlooked should aliases to systemd ever change or get dropped in the future.

I DID say I was curious, and not that it was a matter.

The meat of the post was about what’s needed to create an option for a menu to install just a single component, like reinstalling roundcube, without touching every component, with the understanding that the single update would be to fix a broken component install.

6

I could be wrong, but I don’t think this is intentional or necessary, especially since the hide_output function is also used elsewhere in MiaB along with the systemctl command: Code search results · GitHub

Also, the service command is a fairly simple wrapper that doesn’t really do much on a system with systemd except convert the commands to systemd commands. But check it out yourself, maybe I’m missing something…

cat /usr/sbin/service

Here is the relevant part for systemd:

# When this machine is running systemd, standard service calls are turned into
# systemctl calls.
if [ -n "$is_systemd" ]
then
   UNIT="${SERVICE%.sh}.service"

   case "${ACTION}" in
      restart|status|try-restart)
         exec systemctl $sctl_args ${ACTION} ${UNIT}
      ;;
      start|stop)
         # Follow the principle of least surprise for SysV people:
         # When running "service foo stop" and foo happens to be a service that
         # has one or more .socket files, we also stop the .socket units.
         # Users who need more control will use systemctl directly.
         for unit in $(systemctl list-unit-files --full --type=socket 2>/dev/null | sed -ne 's/\.socket\s*[a-z]*\s*$/.socket/p'); do
             if [ "$(systemctl -p Triggers show $unit)" = "Triggers=${UNIT}" ]; then
                systemctl $sctl_args ${ACTION} $unit
             fi
         done
         exec systemctl $sctl_args ${ACTION} ${UNIT}
      ;;
      reload)
         _canreload="$(systemctl -p CanReload show ${UNIT} 2>/dev/null)"
         # Don't block on reload requests during bootup and shutdown
         # from units/hooks and simply schedule the task.
         if ! systemctl --quiet is-system-running; then
              sctl_args="--no-block"
         fi
         if [ "$_canreload" = "CanReload=no" ]; then
            # The reload action falls back to the sysv init script just in case
            # the systemd service file does not (yet) support reload for a
            # specific service.
            run_via_sysvinit
         else
            exec systemctl $sctl_args reload "${UNIT}"
         fi
         ;;
      force-stop)
         exec systemctl --signal=KILL kill "${UNIT}"
         ;;
      force-reload)
         _canreload="$(systemctl -p CanReload show ${UNIT} 2>/dev/null)"
         if [ "$_canreload" = "CanReload=no" ]; then
            exec systemctl $sctl_args restart "${UNIT}"
         else
            exec systemctl $sctl_args reload "${UNIT}"
         fi
         ;;
      *)
         # We try to run non-standard actions by running
         # the init script directly.
         run_via_sysvinit
         ;;
   esac
fi
7

There’s nothing intentional, just historic growth. I believe the line systemctl enable fail2ban was added later, when systemd was already a thing.

2 Likes
8

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.