I needed to do a fresh install for my little mini computer home server after a borked upgrade from stable to testing necessitated by a hardware upgrade (a new Intel n150 board/graphics). I used [Debian GNU/Linux trixie-DI-alpha1 _Trixie_ - Official Alpha amd64 NETINST with firmware 20241230-11:26] to reinstall my OS.
I restored my programs and data and found that I could not connect to my server using samba, my approx HTTP-based proxy server for Debian-style package archives or the apache2 web server, making the install pretty useless to me as a home server. I could ping the new server and connect using ssh, but that was it. Also, samba, apache2 & approx all worked from the machine itself. If I had had hair I would have been pulling it out.
Finally it occurred to me that there might be a firewall running (sue me, I'm slow on the uptake and I've never had a firewall installed and enabled by default in 20 years of using Debian and Ubuntu).Ouch. OK, it is easy enough to disable the service with:Everything was working properly again. I can figure out how to permanently disable, remove or make rules for firewalld later.
From glancing over my /var/log/apt/history.log file it looks like firewalld:amd64 (2.3.0-1, automatic) was installed at the time I ran the installer, not dragged in as a dependency with some other package.
If that is the case I think it is not a good idea to have firewalld enabled by default without having some sort of mechanism in place to warn the user that the firewall is rejecting service requests and maybe point the user to a GUI tool to configure the firewall (I gather plasma-firewall:amd64 was installed at the same time, I'm not in front of the screen at the moment, so I haven't played with it). Maybe I'm in a minority of one, but this was very unexpected & jarring behaviour to me.
I restored my programs and data and found that I could not connect to my server using samba, my approx HTTP-based proxy server for Debian-style package archives or the apache2 web server, making the install pretty useless to me as a home server. I could ping the new server and connect using ssh, but that was it. Also, samba, apache2 & approx all worked from the machine itself. If I had had hair I would have been pulling it out.
Finally it occurred to me that there might be a firewall running (sue me, I'm slow on the uptake and I've never had a firewall installed and enabled by default in 20 years of using Debian and Ubuntu).
Code:
$ systemctl --type=service UNIT LOAD ACTIVE SUB DESCRIPTION> accounts-daemon.service loaded active running Accounts S> apache2.service loaded active running The Apache> apparmor.service loaded active exited Load AppAr> cron.service loaded active running Regular ba> cryptmount.service loaded active exited cryptmount> cups-browsed.service loaded active running Make remot> cups.service loaded active running CUPS Sched> dbus.service loaded active running D-Bus Syst> firewalld.service loaded active running firewalld >
Code:
service firewalld stop
From glancing over my /var/log/apt/history.log file it looks like firewalld:amd64 (2.3.0-1, automatic) was installed at the time I ran the installer, not dragged in as a dependency with some other package.
If that is the case I think it is not a good idea to have firewalld enabled by default without having some sort of mechanism in place to warn the user that the firewall is rejecting service requests and maybe point the user to a GUI tool to configure the firewall (I gather plasma-firewall:amd64 was installed at the same time, I'm not in front of the screen at the moment, so I haven't played with it). Maybe I'm in a minority of one, but this was very unexpected & jarring behaviour to me.
Statistics: Posted by Praxis — 2025-01-14 19:53 — Replies 0 — Views 31