Description of problem: For example you want to open the ssh Port, you use the config tool and it's says the port has been opened. You still can't connect and iptables -L says everything is closed. Version-Release number of selected component (if applicable): Current How reproducible: Always f.e. with ssh Steps to Reproduce: 1. open ssh port through system-config-firewall 2. try to connect 3. Actual results: You can't connect. Expected results: The port is opened and you are able to connect. Additional info:
Take a look on this conversation. http://lists.fedoraproject.org/pipermail/test/2011-August/102223.html
system-config-firewall does not work as it is expected to. After applying, the firewall still does not work, contrary to what one would expect.
Please add /etc/sysconfig/system-cofig-firewall and also 1) the output of the iptables-save command altogether with /etc/sysconfig/iptables and 2) the output of the ip6tables-save command altogether with /etc/sysconfig/ip6tables
I haven't tested to make sure I'm right, but from memory, what I find to be the case is that the default firewall config blocks port 22, but s-c-f *thinks* the default config allows port 22; so the first time you fire up s-c-f it has 'ssh' checked (i.e. it thinks port 22 is open), but if you do iptables -L on a fresh install, port 22 is not open. I think I found that if you uncheck ssh, hit Apply, re-check ssh, hit Apply again, it does the job and port 22 is now truly open.
(In reply to comment #4) > I haven't tested to make sure I'm right, but from memory, what I find to be the > case is that the default firewall config blocks port 22, but s-c-f *thinks* the > default config allows port 22; so the first time you fire up s-c-f it has 'ssh' > checked (i.e. it thinks port 22 is open), but if you do iptables -L on a fresh > install, port 22 is not open. > > I think I found that if you uncheck ssh, hit Apply, re-check ssh, hit Apply > again, it does the job and port 22 is now truly open. Yes, this is exactly what happens. I just spent the obligatory two hours wondering why I'd forgotten how to ssh, and then found this bug. Disabled the (GUI) firewall, saved. Re-enabled the (GUI) firewall, save. Suddenly SSH works as expected.
Do you have the installation log file? Is there an error about the firewall in it? The initial firewall configuration is done in the installer.
Still broken after an install to hard drive from Fedora-16-i686-Live-Desktop.iso. Changing Version to 16. Unlike an install from install image, I see no file /root/install.log. Is it located somewhere else after installing from a live image, or named differently?
I, too, have been hit by this bug. I think that it has been confirmed, and obtaining the asked-for information requires a fresh installation, so I suggest that the "needinfo" indication should be removed.
(In reply to comment #8) > I think that it has been confirmed, and obtaining the asked-for information > requires a fresh installation, so I suggest that the "needinfo" indication > should be removed. Not to mention that I couldn't find the installation log file, and it's not clear to me that it even exists on a live install. If anyone knows otherwise, can they specify exactly where it is? If I knew, I could do a VM test install and provide the info.
it usually shows up in /tmp during the install process and /var/log/anaconda post-install. also check /root. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
After install, there is nothing in /root except anaconda-ks.cfg. During install, there were several .log files in /tmp, and I saved those after the install finished, prior to rebooting (which deleted them). (All these files were originally owned by root, obviously, these are my copies.) -rw-r--r--. 1 andre andre 15692 Nov 24 18:06 anaconda.log -rw-r--r--. 1 andre andre 99 Nov 24 18:06 ifcfg.log -rw-r--r--. 1 andre andre 89625 Nov 24 18:06 program.log -rw-r--r--. 1 andre andre 203161 Nov 24 18:06 storage.log After rebooting, /var/log/anaconda was created, and the corresponding files are also there, but slightly shorter. The differences consist solely of missing lines in the /var/log/anaconda files. -rw-------. 1 andre andre 99 Nov 24 18:06 anaconda.ifcfg.log -rw-------. 1 andre andre 13897 Nov 24 18:06 anaconda.log -rw-------. 1 andre andre 88642 Nov 24 18:06 anaconda.program.log -rw-------. 1 andre andre 202027 Nov 24 18:06 anaconda.storage.log Here are the differences: [andre@compaq-pc F16-Live-i686]$ diff anaconda.log anaconda/anaconda.log 170,190d169 < 18:06:56,438 INFO anaconda: dispatch: leaving (1) step copylogs < 18:06:56,438 INFO anaconda: dispatch: moving (1) to step methodcomplete < 18:06:56,439 DEBUG anaconda: dispatch: methodcomplete is a direct step < 18:06:56,439 INFO anaconda: dispatch: leaving (1) step methodcomplete < 18:06:56,440 INFO anaconda: dispatch: moving (1) to step postscripts < 18:06:56,440 DEBUG anaconda: dispatch: postscripts is a direct step < 18:06:56,441 INFO anaconda: dispatch: leaving (1) step postscripts < 18:06:56,441 INFO anaconda: dispatch: moving (1) to step dopostaction < 18:06:56,442 DEBUG anaconda: dispatch: dopostaction is a direct step < 18:06:56,452 DEBUG anaconda: isys.py:umount()- going to unmount /mnt/sysimage/sys/fs/selinux, removeDir = False < 18:06:56,525 DEBUG anaconda: isys.py:umount()- going to unmount /mnt/sysimage/sys, removeDir = False < 18:06:56,559 DEBUG anaconda: isys.py:umount()- going to unmount /mnt/sysimage/proc/bus/usb, removeDir = False < 18:06:56,598 DEBUG anaconda: isys.py:umount()- going to unmount /mnt/sysimage/proc, removeDir = False < 18:06:56,634 DEBUG anaconda: isys.py:umount()- going to unmount /mnt/sysimage/dev/shm, removeDir = False < 18:06:56,666 DEBUG anaconda: isys.py:umount()- going to unmount /mnt/sysimage/dev/pts, removeDir = False < 18:06:56,703 DEBUG anaconda: isys.py:umount()- going to unmount /mnt/sysimage/dev, removeDir = False < 18:06:56,793 DEBUG anaconda: isys.py:umount()- going to unmount /mnt/sysimage/boot, removeDir = False < 18:06:57,150 DEBUG anaconda: isys.py:umount()- going to unmount /mnt/sysimage, removeDir = False < 18:06:58,180 ERR anaconda: Unable to unmount filesystems: [Errno 39] Directory not empty: '/mnt/sysimage' < 18:06:58,188 INFO anaconda: dispatch: leaving (1) step dopostaction < 18:06:58,202 INFO anaconda: dispatch: moving (1) to step complete [andre@compaq-pc F16-Live-i686]$ [andre@compaq-pc F16-Live-i686]$ diff program.log anaconda/anaconda.program.log 1254,1266d1253 < 23:06:56,466 INFO program: Running... /bin/umount /mnt/sysimage/sys/fs/selinux < 23:06:56,534 INFO program: Running... /bin/umount /mnt/sysimage/sys < 23:06:56,573 INFO program: Running... /bin/umount /mnt/sysimage/proc/bus/usb < 23:06:56,607 INFO program: Running... /bin/umount /mnt/sysimage/proc < 23:06:56,642 INFO program: Running... /bin/umount /mnt/sysimage/dev/shm < 23:06:56,674 INFO program: Running... /bin/umount /mnt/sysimage/dev/pts < 23:06:56,711 INFO program: Running... /bin/umount /mnt/sysimage/dev < 18:06:56,736 INFO program: Running... udevadm settle --timeout=300 < 23:06:56,806 INFO program: Running... /bin/umount /mnt/sysimage/boot < 18:06:56,999 INFO program: Running... udevadm settle --timeout=300 < 23:06:57,159 INFO program: Running... /bin/umount /mnt/sysimage < 18:06:57,453 INFO program: Running... udevadm settle --timeout=300 < 18:06:57,525 INFO program: Running... lvm lvchange -a n --config devices { filter=["r|/loop5$|","r|/loop6$|","r|/loop7$|"] } VolGroup/lv_root [andre@compaq-pc F16-Live-i686]$ [andre@compaq-pc F16-Live-i686]$ diff storage.log anaconda/anaconda.storage.log 3079,3088d3078 < 18:06:56,521 DEBUG storage: NoDevice.teardown: selinuxfs ; status: False ; controllable: True ; < 18:06:56,557 DEBUG storage: NoDevice.teardown: sysfs ; status: False ; controllable: True ; < 18:06:56,596 DEBUG storage: NoDevice.teardown: usbfs ; status: False ; controllable: True ; < 18:06:56,631 DEBUG storage: NoDevice.teardown: proc ; status: False ; controllable: True ; < 18:06:56,664 DEBUG storage: NoDevice.teardown: tmpfs ; status: False ; controllable: True ; < 18:06:56,700 DEBUG storage: NoDevice.teardown: devpts ; status: False ; controllable: True ; < 18:06:56,731 DEBUG storage: DirectoryDevice.teardown: /dev ; status: True ; controllable: True ; < 18:06:56,983 DEBUG storage: PartitionDevice.teardown: sda2 ; status: True ; controllable: True ; < 18:06:57,444 DEBUG storage: LVMLogicalVolumeDevice.teardown: VolGroup-lv_root ; status: True ; controllable: True ; < 18:06:57,523 DEBUG storage: LVMLogicalVolumeDevice._teardown: VolGroup-lv_root ; status: True ; controllable: True ; [andre@compaq-pc F16-Live-i686]$ I will attach the /var/log/anaconda versions of the files, and save the VM for now in case any more information is needed.
Created attachment 536081 [details] anaconda.ifcfg.log
Created attachment 536082 [details] anaconda.log
Created attachment 536083 [details] anaconda.program.log
Created attachment 536084 [details] anaconda.storage.log
Ok, using the live installer, I was able to verify this. It seems that the live installer is providing config files for the firewall that do not match. It is strange that the firewall config tool is not used to generate the files. /etc/sysconfig/system-config-firewall has been generated by anaconda, but /etc/sysconfig/iptables and /etc/sysconfig/ip6tables are copies from the live image. Please use the firewall configuration tool also in the live installer to generate a valid firewall configuration. Reassigning to anaconda.
/etc/sysconfig/system-config-firewall: # system-config-firewall config written by anaconda --service=ssh /etc/sysconfig/iptables and /etc/sysconfig/ip6tables do not have any open service or port.
*** Bug 769339 has been marked as a duplicate of this bug. ***
Hello, since an update (sry, I can't remember which it was) it works for me. Does this bug still occurs for somebody else? Otherwise I would close it. Regards Michael
I quite don't understand what you are trying to do. If you are trying to open ssh during the install, pass the sshd cmdline option to the kernel. If you are trying to open ssh after the install that isn't an anaconda bug. system-config-firewall is only written during a kickstart install, and then only if using lokkit fails, which is logged.
bcl: the bug is post-install, it's hung around for a while: after installation, if you run s-c-firewall it shows port 22 as 'open', but in fact it isn't, it's being blocked in the iptables config. you have to change it to 'closed' in s-c-firewall, apply that, and then change it back to 'open' and apply *that* before 22 will actually be unblocked. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Confirming that this is still present on Fedora 17's 32bit (have not tested 64) live media.
F17 isn't getting any changes and this is all different in F18 anyway.