Bug 733778

Summary: Firewall config doesn't open port
Product: [Fedora] Fedora Reporter: Michael Spahn <any0n3>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 16CC: anaconda-maint-list, awilliam, john.florian, jonathan, klaatu, pfpschneider, robatino, twoerner, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-09-28 19:33:42 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
anaconda.ifcfg.log
none
anaconda.log
none
anaconda.program.log
none
anaconda.storage.log none

Description Michael Spahn 2011-08-26 15:41:14 EDT
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:
Comment 1 Michael Spahn 2011-08-27 05:29:48 EDT
Take a look on this conversation.
http://lists.fedoraproject.org/pipermail/test/2011-August/102223.html
Comment 2 Peter G├╝ckel 2011-08-27 12:04:13 EDT
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.
Comment 3 Thomas Woerner 2011-08-29 09:23:47 EDT
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
Comment 4 Adam Williamson 2011-08-29 20:32:01 EDT
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.
Comment 5 klaatu 2011-09-13 16:49:06 EDT
(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.
Comment 6 Thomas Woerner 2011-09-14 11:33:05 EDT
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.
Comment 7 Andre Robatino 2011-11-09 17:28:18 EST
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?
Comment 8 Peter F. Patel-Schneider 2011-11-10 06:31:51 EST
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.
Comment 9 Andre Robatino 2011-11-24 15:31:25 EST
(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.
Comment 10 Adam Williamson 2011-11-24 17:25:24 EST
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
Comment 11 Andre Robatino 2011-11-24 18:35:58 EST
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.
Comment 12 Andre Robatino 2011-11-24 18:37:33 EST
Created attachment 536081 [details]
anaconda.ifcfg.log
Comment 13 Andre Robatino 2011-11-24 18:38:17 EST
Created attachment 536082 [details]
anaconda.log
Comment 14 Andre Robatino 2011-11-24 18:38:57 EST
Created attachment 536083 [details]
anaconda.program.log
Comment 15 Andre Robatino 2011-11-24 18:39:42 EST
Created attachment 536084 [details]
anaconda.storage.log
Comment 16 Thomas Woerner 2011-11-25 04:28:35 EST
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.
Comment 17 Thomas Woerner 2011-11-25 04:31:00 EST
/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.
Comment 18 Chris Lumens 2011-12-21 13:04:40 EST
*** Bug 769339 has been marked as a duplicate of this bug. ***
Comment 19 Michael Spahn 2012-03-05 11:24:43 EST
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
Comment 20 Brian Lane 2012-03-08 20:27:56 EST
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.
Comment 21 Adam Williamson 2012-03-09 22:09:31 EST
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
Comment 22 klaatu 2012-09-27 08:51:52 EDT
Confirming that this is still present on Fedora 17's 32bit (have not tested 64) live media.
Comment 23 Brian Lane 2012-09-28 19:33:42 EDT
F17 isn't getting any changes and this is all different in F18 anyway.