Sounds like a YaST level thing, rather than SMT.   I would test if just running YaST for other things does the same thing.

A workaround until you get to the root problem with SMT with the firewall running could be a cron job at least once a day to run systemctl disable + systemctl stop

If it is only with those two YaST commands, perhaps then use a short script to start it, ending with the systemctl disable + systemctl stop

Hi Andy,

Thanks, indeed, this is definitely related to YaST. And only with "smt" and "smt-server" modules, the other ones  do not behave like this.

I have tried to debug YaST withY2DEBUG=1, checking /var/log/YaST2/y2log content, it is rather complex for me (no experience with .rb scripts) but I  can see both systemctl enable and start command call for firewalld.

For the moment I have "chmod -x /usr/sbin/firewalld", I know this is wild thing, but at least it does the job.

FYI, I made a small lab and was able to reproduce it

I'm assuming you've been using the MF/OT SMT, rather than the SuSE one.  I'm wondering if it is the same on that version that is a bit closer to the source code work.  

Perhaps see if you can fire up an instance of the SuSE SMT to see if you can duplicate with it.

If you can't do so, or get the same result, it would be worth bringing up this issue in the SuSe community.

Since we are beyond simple troubleshooting of dropping the firewall as a test, why do we need to keep the firewall down on this system?
Firewalls are a good thing, so it would make sense putting more effort into fixing any issues with it, unless there is a stated clear reason to dig into this.  I have one idea, but want to hear yours first ;)

we have our internals firewalls and by default do not enable the software/local one.

BTW, this behaviour "yast smt => firewall" is new to SMT 2, previous version didn't behave like this.

PascalS said:

we have our internals firewalls and by default do not enable the software/local one.

With how good the bad actors are getting at each step of a breach, the boarders are becoming 'cloudy', and that initial foot hold is becoming more and more expected (end users, can't live with them, can't live without them),  stopping the lateral movement within a system is becoming The Thing To Do.  Those local firewalls are one such layer of defence, and while this 'fun' with the yast smt issue is rather Draconian, it is the wave of the future.   We can't have good things (like soft insides of our networks) because of the bad things other people do.

Yes, we can <sigh> together on this change of our larger environment we live in.

Good day, 

I've seen this behavior as well, I have disabled the firewall, and ensured that the service wouldn't restart, and yet there are a number of times during the day(s) that the firewalld.service is running again. Honestly, it's frustrating as SMT clients won't update properly, if they cannot contact/connect with the SMT 2.0 server, I also never saw this behavior with SMT 1.0, and would like to find some type of remediation. I don't if there would be anything in the SLES15-Sp4 forums, I've never actually logged into that service, but happy to try if that becomes needed. Much like you mentioned, in my internal arrangement, I rarely if ever bother with friewalls, certainly for outside connections I would do so, but again internally it seems to be another layer that isn't really needed. 

That being said I've only been running SMT 2.0 to match/mimic my customer arrangement, and might just return to SLES12-SP5 and SMT 1.0 if I cannot figure out the firewall.d.service issue. 

Again I've tried to disable, manually start up, but it seems that it's changing on it's own volition. 

Thank you, 

-DS 

Those 3 commands should help :

# systemctl stop firewalld

# systemctl disable firewalld

# systemctl mask firewalld

3d one is the best one ;-)

ahh,   a mask!

a good trick to remember

let's hope they don't start pulling away our masks in our masquerade/dance of getting our systems to work.

Good day, 

I used this command as well (for now) systemctl mask firewalld and we'll see how things do moving forward. I can usually tell if the firewall service has turned back on because unable to SSH to the server in question. I guess as you had mentioned as well might not be a bad idea to start digging into this and seeing what it would take to keep the firewall up in the future.