This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SMT 2.0 re-enabling firewall

Hi Community,

On SMT 2.0, I noticed the following:

When firewall is disable (stopped + "Do not start", in YaST), (same if I : systemctl disable + systemctl stop)

This is automatically changed when launching "yast smt" or "yast smt-server", this is starting firewall and changing to "start on boot", even if I do "nothing" within yast smt and exit with "Cancel"

This is new behaviour  in SMT 2.

SMT 1 didn't behave like this.

Any idea, how to disable that behaviour ?

Thanks,

Pascal

Everyone is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid. [A. Einstein]

Tags:

Parents
  • 0  

    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

    ________________________

    Andy of KonecnyConsulting.ca in Toronto
    Please use the "Like" and/or "Verified Answers" as appropriate as that helps us all.

  • 0 in reply to   

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

    Everyone is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid. [A. Einstein]

  • 0   in reply to 

    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 ;)

    ________________________

    Andy of KonecnyConsulting.ca in Toronto
    Please use the "Like" and/or "Verified Answers" as appropriate as that helps us all.

  • 0 in reply to   

    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.

    Everyone is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid. [A. Einstein]

Reply
  • 0 in reply to   

    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.

    Everyone is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid. [A. Einstein]

Children
  • 0   in reply to 
    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.

    ________________________

    Andy of KonecnyConsulting.ca in Toronto
    Please use the "Like" and/or "Verified Answers" as appropriate as that helps us all.