Even though I chose not to install a firewall, and told it proceed anyway without one, something decided I needed one anyway, so I couldn't ssh into the box after installation unless I had done a service iptables stop Version-Release number of selected component (if applicable): How reproducible: This has happened before, though I thought it had gotten fixed already.
I haven't seen this and I usually disable the firewall on my installs :) What sort of install did you do? I need steps to be able to reproduce.
I booted yesterdays boot.iso for amd64, and did an nfs install. Can't really think of any steps to follow other than 'say no to firewall'.
Also observed in kickstart installs with 'firewall --disabled'.
FWIW, the behavior seems to depend on which packages are installed. In particular, minimal installs do not have the unwanted firewall rules in place and everything installs do. Maybe a package is doing this in %post?
Created attachment 98694 [details] /etc/sysconfig/iptables from 'firewall --disabled' kickstart install I can't find anything in an package scripts that would do this. Attaching the offending iptables config.
running /usr/bin/system-config-securitylevel-tui -qn --disabled gets me the exact same /etc/sysconfig/iptables contents. Reassigning bug.
Brent, even with selinux in nonenforcing mode, running '/usr/bin/system-config-securitylevel-tui -qn --disabled' yields the same (nondisabled) firewall config.
Looks like lokkit is ignoring the commandline options and is using what's in the config file. I think notting is looking at it.
Fixed in 1.3.7-1.
I just installed from the latest tree. s-c-securitylevel-1.3.7-1 and anaconda-9.91-6 are in the tree. I disabled the firewall during install but I'm still firewalled out of the box.
What's your anaconda-ks.cfg look like?
Created attachment 98837 [details] anaconds-ks.cfg
Fixed in 1.3.8-1.
The command I gave above, '/usr/bin/system-config-securitylevel-tui -qn --disabled', is working correctly in the installed system. As is '/usr/sbin/lokkit --quiet --nostart --disabled', which is the invocation that anaconda uses. Both these statements apply to version 1.3.7-1.
Still seeing in -re0324.1 * system-config-securitylevel-tui-1.3.8-1.i386 * anaconda-9.91-6.i386 See above comment. This could be anaconda.
Does this work better in post-test2 trees?
I'll try an install from todays tree later today.
Looks fixed to me.