Heads up RE: ufw as new Arch user

just wanted to add a heads-up warning here for other new Arch users.

I did my fist Arch installs a few months back and one of my first orders of business was to make sure ufw firewall was running.
I found out some time later that apparently…
what I had done to PERMANENTLY enable it in other distros,
had only served to enable it for that particular login session in Arch,
and upon reboot- and ever since- it had been OFF!

apparently you must run the command…
sudo systemctl enable ufw.service
to actually make it startup on boot every time.

check yours by running…
sudo ufw status

FYI
all the best

I don’t want to be the bringer of “bad news,” but that’s what you’re supposed to do on all major distros. Some of them, e.g. ubuntu comes with ufw enabled in systemd by default.

You need might want to read about init systems, process supervision and service managers. Most major distros use systemd with its accompanying systemctl command.

If you’re coming from windows, think of it like Task Scheduler. If you have no prior knowledge of auto-starting programs / daemons on system start-up, then think of it like services that start up without a user needing to log in.

The systemd suite is basically an integration of init, process supervisor and service manager, all in one. It’s the first thing that happens on your system and it’s the process responsible for determining the order of activating services (like loading up udev to detect devices and device changes, loading up kernel modules for certain file system support or other drivers, load up the networking state, which then allows you to load up networked services and so on).

Linux journey has a bit of information there, but it’s at a very basic level. You can read it in 20 minutes.
https://linuxjourney.com/lesson/sysv-overview

1 Like

in Mint I think it had actually been GUFW I used, and I did need to turn it ON, but that took care of it on boot thereafter. pretty user it was the same way in Mandrake and Mandriva years ago.

so just to report back to this thread- having tread this ground again…
I installed ufw in Arch again on a new machine just now and after installation I ran…

  • sudo ufw enable -
  • and the response is…
  • " Firewall is active and enabled on system startup " !?
    however it IS NOT yet enabled on system startup without the
    sudo systemctl enable ufw.service command.

this had been a problem for me because, had it actually been enabled on system startup, that would have matched the behavior of enabling it previously in GUFW under Ubuntu/Mint and others.

i would be curious to know if there are other distros where getting the message " Firewall is active and enabled on system startup "
is infact actually true.

very interesting.

There’s 2 methods of starting programs on a linux (and unix-ish) distros:

  • at system start-up in the process supervisor / system manager (i.e. sysvinit, runit, systemd)
  • at user login (using .bashrc or .bash_profile)

What you were doing with gufw was to start the firewall when you logged in, instead of enabling it globally (system wide). There’s pros and cons for each, but you generally put stuff in the service manager to have them always on and you put things in your user profile so things only get enabled when you log in (e.g. in some secure environments, where the user profile is encrypted, the profile doesn’t get decrypted until you log in - it makes no sense to decrypt it just because the system is up, particularly if this is a multi-user system).

thanks for more background infos on this ThatGuyB…

do you have any insight as to why ufw (not gufw)
-in response to the terminal command…
sudo ufw enable
…responds with
" Firewall is active and enabled on system startup " ???

although the correct command has been established,
the above is neither true for system startup nor user login in Arch…
but must be true? somewhere under some conditions?

thanks!

For that, I can’t say without doing some debugging on it. It might either try to set up a startup command for sysvinit, which is not compatible with systemd, the message might be wrong (and it’s actually doing that on user login), or maybe some other kind of bug.

To get the program to start on boot-up, you’d need to get a prompt to insert sudo credentials. If it’s not asking for them, then idk what it’s doing. If you get these, but it doesn’t enable it on systemd with the systemctl enable, then idk.

I personally don’t trust automated systems and I’m very aware of what’s going on on my systems. I always make sure that things start on boot and I have nothing that starts on user login. It does take time to learn how your system works. For now, all you need to know is that if you want to have things start on boot, you must systemctl enable the services (assuming they exist).